Nobody Understands REST or HTTP • Hacker News Board

Re: Nobody Understands REST or HTTP

#41

Post by lazylland » Sun, Jul 03, 2011, 10:27 PM UTC

Here's something I've observed:

i) most successful "RESTful" APIs don't really follow all the REST principles (e.g Flickr, Amazon, Dropbox). My thumb rule is this: If an API does not start from a "mother" URI that gives you the most updated list of resources that can then be requested by the application, it is not really HATEOAS.

ii) a purely resource-oriented view of your entire API space shoehorns you into doing really strange things to keep REST "purity"

So my conclusion is that using an architecture/concept originally intended for humans navigating hypermedia documents may not be a natural fit for parts of your API that cannot be modeled as such. See the Dropbox REST API documentation (http://www.dropbox.com/developers/docs#api-specification) (" Section: Deviations From Standard REST Style") to see an example of the pragmatic decisions taken.

Re: Nobody Understands REST or HTTP

#42

Post by ericmoritz » Sun, Jul 03, 2011, 10:30 PM UTC

pornel wrote: post #30

Sidnicious wrote: post #15

I 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…

/search/bass/sort/artist/ That doesn't look like a hierarchical resource. You probably don't list sort options under /search/bass/sort/, and even then /search/bass/sort/artist/ wouldn't be logical subset of that. This URL looks more like a different view on /search/bass resource, so /search/bass?sort=artist is IMHO more appropriate.

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 with this URL:

/search/?query=bass&page=10

This is a different resource than the previous. In this case, sometimes it feels like the page should be a member of the search collection. It's up to you whether you prefer a URL like this

/search/pages/10?query=bass

In my head that is incorrect because to me the query string manipulates the last item in the hierarchy which is "pages/10". So the order of operations would look like this:

1. Select the first page from the search collection 2. return only items on the first page that contain the word "bass"

Re: Nobody Understands REST or HTTP

#43

Post by Omni5cience » Sun, Jul 03, 2011, 10:31 PM UTC

ericmoritz wrote: post #36

jballanc wrote: post #11

Very good read, and thorough. I particularly like the transaction example. It seems like a common idiom that trips people up with REST. However, I do have a problem with REST that I've been dealing with lately. Specifically, the question of web-hooks. Many services today allow you to pass a URL that they will hit with a POST request whenever something happens. A good example is the GitHub post-receive hook ( http://h…

What I've seen in the past (mainly from Pylons) is to have an extension on the end of the URL so: /updates/ has a default format say XML and then there's a JSON resource called /updates.json, /updates.txt, etc. Keep in mind what the R in REST stands for. Each resource is a representation of internal data. You can have multiple representations under different URLs even though they're powered by the same internal data…

One small nitpick, it's actually the RE in REST

Re: Nobody Understands REST or HTTP

#44

Post by lazylland » Sun, Jul 03, 2011, 10:32 PM UTC

strmpnk wrote: post #13

strmpnk wrote: post #8

I've personally given up trying to save the term REST. It was hijacked and will never recover completely at this point. What I've been looking for is a good alternative name. Sometimes I'll write out representational state transfer which is clever enough to get past most REST pretenders but I have yet to find something short.

I guess I should clarify my statement. The article is right on the dot. The point here is that arguments like this really need a new label. That's all I'll say.

But I didn't think that he used the terms too loosely. What do you think was lacking/superflous in his arguments ?

Re: Nobody Understands REST or HTTP

#45

Post by lazylland » Sun, Jul 03, 2011, 10:36 PM UTC

binarymax wrote: post #34

This is a great article. One challenge I am facing now is both building a RESTful API, along with a UI that uses the API. The biggest question I have is the use of shebangs in urls with the ajaxy app. We must support IE so pushState is out, but shebang just seems like a hack. I think at this point I have no choice but to implement shebang but I wonder if there are any viable alternatives?

Try this : https://github.com/balupton/History.js

Re: Nobody Understands REST or HTTP

#46

Post by lazylland » Sun, Jul 03, 2011, 10:37 PM UTC

binarymax wrote: post #34

This is a great article. One challenge I am facing now is both building a RESTful API, along with a UI that uses the API. The biggest question I have is the use of shebangs in urls with the ajaxy app. We must support IE so pushState is out, but shebang just seems like a hack. I think at this point I have no choice but to implement shebang but I wonder if there are any viable alternatives?

Try this : https://github.com/balupton/History.js

Re: Nobody Understands REST or HTTP

#47

Post by dreamdu5t » Sun, Jul 03, 2011, 10:37 PM UTC

REST is great and all, but browsers don't allow it. The only thing you can do is GET, nothing else is supported cross-domain.

No matter your thoughts on REST, it's dead. It's never happening. This argument has gone nowhere for 10 years.

Very few if any websites conform to the spec, and browsers have made it impossible to do so.

Re: Nobody Understands REST or HTTP

#48

Post by clintjhill » Sun, Jul 03, 2011, 10:40 PM UTC

Content Negotiation is a critical part of REST APIs and it's my observation that most simply ignore or default to JSON in all cases. Good REST APIs allow the client to "choose" the mime type. Without this part of REST - you have no "representational".

On that topic, to rely on an 'Accept' header is pretty risky. That presumes the client will always have control over the headers. It is in my opinion always wiser to make the API determine mime type by extension (.html, .xml, .json etc).

Re: Nobody Understands REST or HTTP

#49

Post by mberning » Sun, Jul 03, 2011, 10:40 PM UTC

I really dislike creating resources to represent transient actions. Not a big deal in the case of a bank transaction as that is something you could easily imagine needing to be stored for later retrieval. A different example is relating one social network friend to another or searching for specific people on the site. Those are things that, to me, are much more borderline and I would err on the side of not representing them as resources.

Re: Nobody Understands REST or HTTP

#50

Post by strmpnk » Sun, Jul 03, 2011, 10:42 PM UTC

lazylland wrote: post #44

strmpnk wrote: post #13

Earlier quoted context omitted.

I guess I should clarify my statement. The article is right on the dot. The point here is that arguments like this really need a new label. That's all I'll say.

But I didn't think that he used the terms too loosely. What do you think was lacking/superflous in his arguments ?

I meant this to apply in general. Rather than try to correct people we should introduce people into the architectural style and since REST already means something to many, it only seeds confusion.