Dudes, this is so not REST

After reading the title I was all set to come in here and complain about "REST" Nazis and make some comment about how real life situations tend to supersede strict adherence to conventions.<p>But then I read the article and I have to admit this is a pretty egregious break with how REST services are supposed to work.

Actually, what the blog author is talking about is a resource-oriented architecture (ROA), which is typically implemented in a RESTful fashion over HTTP but has recently been conflated with REST itself. ROA != REST.

Why does it matter? Ok, I agree that you probably shouldn't label something with an incorrect term, but does not having more than one URL, and not using the different HTTP methods really make a difference in terms of programmer usability?<p>I personally find that sometimes I have trouble spotting the "oh! I forgot to make it DELETE instead of GET" bugs. When the parameters of the API are all in the url and/or query, it feels better encapsulated.<p>(promise I'm not flaming, and I fully expect to get told, yes it matters, and here's why! ;)

I once worked on a project where 'REST' was synonymous with 'putting query data into the URL before the query string', and this was done so that the webserver could cache the response.<p>I died a little inside every time I wrote a 'Restful' servlet there.

This is an increasingly common extension of the REST paradigm. Google ran into a number of problems with the restrictions of REST, so their new APIs all work this way. See their justification in this video: <a href="http://www.google.com/events/io/2010/sessions/how-google-builds-apis.html" rel="nofollow">http://www.google.com/events/io/2010/sessions/how-google-bui...</a>

'''Maybe we should just give up on the term REST, since it’s become so diluted as to mean nothing more than "HTTP API that’s not as hard to use as SOAP"?'''<p>To be fair, I thought we were at this point already. It seems safer to assume that when one advertises a "RESTful API" they are really referring to a "REST-like" API which basically means "Hey, we don't use sessions!"<p>While I believe that the term is already diluted to that point, I still think it's valid to point out when people are doing it wrong.

REST is now just a generic term for any HTTP API that's not SOAP. Like Xerox and Kleenex, the popular usage is technically incorrect, but in practice, it doesn't matter.<p>Most REST API consumers today are more like CURL than a web browser. In the CURL-like case, the RPC pattern works quite well. HATEOS and other browser-centric REST ideas often just don't fit naturally into a simple API consuming app. People need to move on.

"It screams RPC. There is so much coupling on display that it should be given an X rating."<p>-- Roy Fielding @ <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="nofollow">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...</a>

This sort of API is not RESTful at all, regardless of whether the method name is in the HTTP header or a form variable. It's still an application-specific protocol that requires out-of-band knowledge to use. REST resources are supposed to be self-describing, which doesn't make much sense for an API like this. RPC is what is required here, so just tunnel RPC over HTTP in whatever way is most practical. And don't call it REST.<p>If you want a bucket of cold water over the head on this topic: <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="nofollow">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...</a>

Instead of fetishizing REST for its own sake, how about appreciating an HTTP API that can be used (read/written) with a browser via form elements and hrefs?

We might be getting close to this point: <i>Maybe we should just give up on the term REST, since it’s become so diluted as to mean nothing more than “HTTP API that’s not as hard to use as SOAP”?</i><p>This is a shame, because RESTful APIs are (for me, anyway) usually a joy to build and to use.

I've worked with APIs that return XML containing one node, which contains escaped XML. So when I read something like this it doesn't seem that bad.

In the Java world REST was pretty cool for about 18 months. And then annotations came out, and instead of all the JAX-RPC bondage and discipline, you get JAX-WS, where to make something a webservice literally all you need to do is shove the @WebService annotation on it and you are good to go†.<p>All the WSDL and SOAP crap gets auto-generated for you. Thereby eliminating in a single stroke REST's advantage.<p>Now, it is true that there is some stuff†† you can do with SOAP that you can't do with JAX-WS, but really unless you like making life difficult for yourself then don't.<p>Especially for a big Java to Java solution there doesn't seem to be any compelling reason to go with REST anymore. Even if <i>everything</i> you do maps exactly to the four SQL ops (select, update, insert, delete) it is still just as easy to use the annotation as it would be to use REST.<p>†C# has something similar I think.<p>††Example: JAX-WS is limited to what you can do with a method and parameters in Java. In your SOAP schema you can specify for instance that the array you get passed shall have between 1 and 3 members, two is okay but 4 is right out. Whereas in Java (and hence JAX-WS) if you have an Array parameter, you can't specify that it must have a certain number of elements in it.

The author gives WebDAV as an example of a good standardized REST API.<p>Is adding new HTTP methods (like PROPFIND, MOVE, COPY, etc.) considered to be RESTful? I always thought you were supposed to structure all actions around the main 6, and add extra functionality in the data payload or query parameters.

FTA &#62; In fact this is why Tim Berners-Lee used the word “method” in the HTTP protocol in the first place.<p>Does he have a source for this? Coincidentally I had just read the HTTP 0.9 the other day and I didn't see "method" being used that way at all. I think method, in HTTP, just means "a means to retrieve / put data", not method in the object oriented sense.

Yep, our API isn't really technically REST in the classical use of the term. We changed some of our wording and made a blog post: <a href="http://developer.rdio.com/blog/read/No_REST_for_the_wicked" rel="nofollow">http://developer.rdio.com/blog/read/No_REST_for_the_wicked</a>

Summary:<p>Rdo: "Yeah, we have POST!"<p>Thought Palace: "What about the rest?"

This is a good example of a REST anti pattern. It can be easier to understand REST, when you know what it's not.

I am all with you on using GET and POST properly, but is there any REST API that actually uses PUT and DELETE?

Yes! Yes! Yes!<p>"HTTP API that’s not as hard to use as SOAP"<p>My current employer calls our API ...<p>... RESTful like .

<i>It’s object-oriented, where objects are identified by URLs</i><p>I'm not so sure that "object-oriented" is the right term here, but totally agree with the premise: this isn't REST. It's more like XML-RPC Jr.

So it's an HTTP-based API rather than true REST. Move on. <i>shrug</i>

how about calling it RESTish? <a href="http://news.ycombinator.com/item?id=2242162" rel="nofollow">http://news.ycombinator.com/item?id=2242162</a>