If nobody understands REST, and as other articles have claimed, nobody does it right, then why do we keep trying to use it?
Switch to something simple that everyone can understand like JSON-RPC and quit worrying about pedantry.
Nobody Understands REST or HTTP
121–130 of 141 posts
Re: Nobody Understands REST or HTTP
#122Earlier quoted context omitted.
The standard is to use / for hierarchal data and URL params to alter the resource's content. For instance: /search/ would be an empty search, and for the sake of argument let us say that it returns the entire collection. /search/?query=bass This would restrict the collection to return only records that contain the word "bass". Based on the way that URLs are defined, these are considered separate resources. The same w…
I would say it would be a different (limited) representation of the same resource.
In HTTP resources are the things identified by the URL, so if you change the query parameters you are addressing a different resource.
Re: Nobody Understands REST or HTTP
#123I thought I finally had REST figured out until I read this. Does anyone else see a diminishing return on pedantically following the REST-prescribed design and actually creating an API that people are familiar with out of the gate? I feel like if I followed this article to the T in my current design, anyone trying to integrate with it would spend so much time reading my API documentation just to figure out why they we…
You might be interested in "RESTful Web Services Cookbook", it covers some of the topics you discuss and is a very pragmatic book.
Re: Nobody Understands REST or HTTP
#124I had a really interesting conversation about this with a coworker a few weeks ago. We were talking about URL design. I argued for URLs like this: /networks/ /networks/girl_talk/ /networks/girl_talk/tracks/ /search?term=bass&sort=artist He argued for URLs like this (note the pluralization): /networks/ /network/girl_talk/ /network/girl_talk/tracks/ /search/bass/sort/artist/ My case boiled down to, “A URL represents th…
Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it. Developers will use either, just do it and provide documentation and be done with it
> Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it.
REST doesn't really care about pretty URIs either, in fact one truism about REST is that people who spend a lot of time worrying about pretty URIs are probably missing the more important aspects of REST.
Oh and I agree with you, people can spend a long time coming up with pretty and hackable URIs and in my experience clients often just don't care (sometimes its worth the effort though).
Re: Nobody Understands REST or HTTP
#125The biggest problem with today's REST implementations is that they're essentially a database serialization layer. Consider how a RESTful Rails model is typically represented as: { book: { id:1, name:"To Kill a Mocking Bird", author_id:2 } } How do you get more info on the author if you only have this piece of information? Rails/ActiveResource guesses through convention: "/authors/2", but that might not be the case, w…
Pagination is implicitly non-restful as page=X can change anytime a new book is added, depending on the ordering getting done.
Roy Fielding's paper says that "temporal services" are OK:
> A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...
Re: Nobody Understands REST or HTTP
#126I thought I finally had REST figured out until I read this. Does anyone else see a diminishing return on pedantically following the REST-prescribed design and actually creating an API that people are familiar with out of the gate? I feel like if I followed this article to the T in my current design, anyone trying to integrate with it would spend so much time reading my API documentation just to figure out why they we…
using object.format is perfectly ok regarding the rest. using headers might be more pure, but its not the biggest issue.
the biggest issue with the rest-wanna-be interfaces is their use of object ids instead of object uris. so that I have to construct my own urls to access stuff.
in a proper restful api you are NEVER supposed to construct your own url. you are supposed to get all the relevant ones from the service.
and this kind of api is actually much more user friendly and allows for much better discovery. you just get the single top api url which has references for all the available collections objects and operations right there in the result.
Re: Nobody Understands REST or HTTP
#127Rest was a really big deal in the Java web-app world for about a year... It was back when early versions of Struts were 'the designated alternative', and in the bad old days of J2EE and JAX-RPC. Then Java EE 5 came out, which solved large chunks of the pain that J2EE inflicted, JAX-RPC got replaced with the infinitely better JAX-WS and there was a new breed of web frameworks as well, which blew Struts out of the wate…
I want to know what part of the Java web world you are talking about exactly?
I just question the concept that REST is in anyway considered to be obsolete within the Java web world. Spring-MVC focuses more and more around this technology, and is also the delivery point for REST web services from spring; Struts 2 has slowly moved more towards RESTfulness; and additionally frameworks like Play have come around.
Re: Nobody Understands REST or HTTP
#128[deleted]
Re: Nobody Understands REST or HTTP
#129I thought I finally had REST figured out until I read this. Does anyone else see a diminishing return on pedantically following the REST-prescribed design and actually creating an API that people are familiar with out of the gate? I feel like if I followed this article to the T in my current design, anyone trying to integrate with it would spend so much time reading my API documentation just to figure out why they we…
using object.format is perfectly ok regarding the rest. using headers might be more pure, but its not the biggest issue. the biggest issue with the rest-wanna-be interfaces is their use of object ids instead of object uris. so that I have to construct my own urls to access stuff. in a proper restful api you are NEVER supposed to construct your own url. you are supposed to get all the relevant ones from the service. a…
Vitaly,
So something like:
GET /image.json/pig.png?size=150x100
GET /image.json?id=pig.png&size=150x100
Re: Nobody Understands REST or HTTP
#130I thought I finally had REST figured out until I read this. Does anyone else see a diminishing return on pedantically following the REST-prescribed design and actually creating an API that people are familiar with out of the gate? I feel like if I followed this article to the T in my current design, anyone trying to integrate with it would spend so much time reading my API documentation just to figure out why they we…
You might be interested in "RESTful Web Services Cookbook", it covers some of the topics you discuss and is a very pragmatic book.
Colin, just grabbed it from Amazon. This is exactly the type of resource I wanted to go through before going live with the API.
Thanks!