Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody Understands REST or HTTP

blog.steveklabnik.com

Post reply on HN
Print view View original

11–20 of 141 posts

Re: Nobody Understands REST or HTTP

#11

Post by jballanc »

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://help.github.com/post-receive-hooks/). So, to be a good student of REST, I create an /update resource for the POST (similar to the /transaction example from the article). However, /updates might come in a variety of formats. Not just JSON vs XML, but GitHub vs Gitorious vs Beanstalk vs etc.

So, how do I handle these "formats". Presumably the "Accept" header is out of the question (unless the provider happened to know about MIME's vendor extensions and used them). So then is it acceptable to add a parameter? Use "/update?from=GitHub" for example? Or, is it appropriate to use an extra path element like "/update/GitHub", since the resource really is a "GitHub update", not just a vanilla "update"?

Re: Nobody Understands REST or HTTP

#12

Post by icebraining »

ericflo wrote: post #3

The problem with posts like these is that they say things like "THIS IS BAD!!!!!1" without saying why.

The problem is if you don't follow those constraints, but still call your system REST. The meaning of the concept is rendered useless by so many people abusing it without understanding what it means.

Re: Nobody Understands REST or HTTP

#13

Post by strmpnk »

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.

Re: Nobody Understands REST or HTTP

#14

Post by ianterrell »

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…

There's no right answer, but it's helpful to think about it from a data modeling point of view.

If where the update comes from would be stored as an attribute (i.e. column in the table), use the parameter option (/update?from=GitHub). If, however, they'd be separate types of updates (i.e. separate tables), use the separate URIs (/update/github or /github_update).

This is an analogy, of course, as there's no need for a 1-to-1 resource-persistance mapping, but it's a useful way of thinking about it, I think.

Re: Nobody Understands REST or HTTP

#15

Post by Sidnicious »

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 the path to a resource. You should be able to remove any number of parts from the end of a URL and be left with a different, meaningful URL. In the case of search, the terms are options that describe what you want returned by the search, not resources.”

His case boiled down to, “A URL is a sentence. You should be able to read a URL as English and get a good idea of what it represents. In the case of search, adding more path components adds words to the sentence to make the search more specific.”

He pointed out (paraphrasing) that URLs are a language — and languages evolve. URLs as paths better embodies the RFC, but a new style of URL might be more meaningful on today’s (and tomorrow’s) web.

Re: Nobody Understands REST or HTTP

#16

Post by icebraining »

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…

I don't see what's the problem. Github is the client, so they POST to you the data, so they should include a 'Content-Type' header with the format of such data. Then you can process it accordingly.

Re: Nobody Understands REST or HTTP

#17

Post by smiler »

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…

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

Re: Nobody Understands REST or HTTP

#18

Post by icebraining »

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…

An URL is just a name. /network/girl_talk is just as valid as /uwef9. HATEOAS means that clients shouldn't know a-priori of any URL except for the entry point.

In the search case, I think your coworker is wrong, since that would mean you have to construct URLs by 'hand', which violates HATEOAS. GET or POST parameters should be used to avoid that.

Re: Nobody Understands REST or HTTP

#19

Post by config_yml »

glenjamin wrote: post #2

Is there any way to make the browser do an Accept: application/csv header on a hyperlink? I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv) While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.

Looking at the newer spec, we should be able to use "hreftype" for content type or "hreflang" for accept language: http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#s_hyper...

I don't know if any browser will implement this or has implemented it, but in real world scenarios we'll probably have to stick with .csv and en/foo or ?locale=en for a couple of years...

Re: Nobody Understands REST or HTTP

#20

Post by glhaynes »

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…

Slash-divided parts of URLs generally seem to me to describe a hierarchy, both because of the traditional structure of many URLs and slashes' traditional usage as a hierarchical path-delimiter. So I personally prefer your proposal because it makes a to-me clearer distinction between the resource that's being specified and the rendering attributes applied to the presentation of that resource. So it seems more obvious at a glance which parts of your URL could be removed/changed and what would happen and it just "feels" more right.
Post reply on HN