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

71–80 of 141 posts

Re: Nobody Understands REST or HTTP

#71

Post by stanleydrew »

rubyrescue wrote: post #68
icebraining wrote: post #63

Earlier quoted context omitted.

>he says version numbers in the url are bad but doesn't say why. Because according to the spec, each resource is named by a single URL, so two URLs name two different resources. But if you put version numbers in the URL, you might end up with http://example.org/v1/rubyrescue and http://example.org/v2/rubyrescue , which according to the spec are two different users but in reality they're the same. >also a v1 user real…

good point, but the point of a restful resource is that the url represents a resource, but then w/accept header versioning, i now need two pieces of data, one of which isn't visible, to properly represent and retrieve a resource. I guess my point is that if i have to pick, i'd rather occasionally have two request urls with a minor version difference that are actually the same resource than two urls that appear to be…

What do you mean by visible? Visible in the URL bar of a browser? The headers are all there in the request, for all to see.

Re: Nobody Understands REST or HTTP

#72

Post by wyuenho »

I read the post and I have to say that he's got a nice flamebait title but totally avoided the thorny issues that people argue about. In fact, I'd like to be pointed to a solution for the following problems:

1. I'm an old Web programmer, and my introduction to the Web started with HTML, not HTTP. I don't just write APIs, I write Web apps. I find it difficult to explain to people what this means:
If you are religiously RESTful, you probably think this is fine. But I'm a religious English reader. When I see the word "action", I think of a verb, not a noun. When I see the word "method", I think of "how", not "what". So when I look at the HTTP spec, all the HTTP "verb"s look to me like how-I-should-do-something, instead of what-to-do, and the resources (URLs) look to me like the what-to-do, instead of what-they-represent.

Small semantics issues I suppose, but here's another one:

2. HTTP is not a programming language, and yet it demands a (very) finite set of actions and an infinite set of objects to model the real world, where there are an infinite number of actions and objects. What I mean is, in Java or whatever OOP language, I can define classes to model objects and define methods in classes to model actions on objects, but I'm not sure if I can do it pragmatically in HTTP without getting yelled at.

3. HTTP statuses. Almost the same problem as the above. I have many different kinds of statuses, not all of them fit in the finite set of HTTP statuses, and they don't always provide the granularity I want. Can I return a non-standard status number? How would the clients behave? I have no idea.

4. Being RESTful means not being stateful. But you see, there's this thing called session and login cookies and many other tracking cookies that I have to take care of. Again, I don't just write APIs, I write Web apps. I would like to not do multiple handshake requests just because a paper says I should. I would also like to not get yelled at when I decide not to.

5. HTTP is RESTful, thus HTTP is REST. Please don't tell me HTTP is the best we can do. Can I have something more minimalist, extensible and powerful enough to model the real world?

-- A troubled Web dev.

Re: Nobody Understands REST or HTTP

#73

Post by stanleydrew »

mainguy wrote: post #65

I've had this discussion about hundred times now. REST "standards" are as important and significant as brace indentation "standards". A big problem with REST is that it is NOT a canonical (or even important) standard, but rather a useful pattern than can be used to make things exposed via HTTP more intuitive. The evil side effect of this is that a metric crapton of architects/engineers are wasting fifty bajillion pro…

I understand your frustration but I think you are misguided. Standards (and their cousins, best practices) are important to think about in order to create diverse yet maintainable and inter-operable systems.

"A big problem with REST is that it is NOT a canonical (or even important) standard, but rather a useful pattern than can be used to make things exposed via HTTP more intuitive."

No, its not meant to make HTTP interfaces "more intuitive". HTTP clients are machines. They don't have intuition. When your web browser hits the HN front page, it isn't using intuition to figure out what links to display.

You can make an argument that for a particular web service, adhering to a particular principle of REST doesn't matter. But you have suggested that the principles of rest never need to be an important consideration for any web service, which I submit is plainly false.

Re: Nobody Understands REST or HTTP

#74

Post by icebraining »

stanleydrew wrote: post #69
icebraining wrote: post #63

Earlier quoted context omitted.

>he says version numbers in the url are bad but doesn't say why. Because according to the spec, each resource is named by a single URL, so two URLs name two different resources. But if you put version numbers in the URL, you might end up with http://example.org/v1/rubyrescue and http://example.org/v2/rubyrescue , which according to the spec are two different users but in reality they're the same. >also a v1 user real…

"Because according to the spec, each resource is named by a single URL, so two URLs name two different resources." I don't think this is technically correct. For instance, you might have a blog with a post at /blog/2011/07/03/why-i-love-rest and you might have /blog/current represent the same resource until you post something new. This seems like a valid case in which two different URIs name the same resource. If you…

Hmm, I think that those URLs are still different resources; one is 'the current post' and the other is 'the post named "Why I love REST"'. I would do a 302 from the latter to the former.

Re: Nobody Understands REST or HTTP

#75

Post by stanleydrew »

icebraining wrote: post #74
stanleydrew wrote: post #69

Earlier quoted context omitted.

"Because according to the spec, each resource is named by a single URL, so two URLs name two different resources." I don't think this is technically correct. For instance, you might have a blog with a post at /blog/2011/07/03/why-i-love-rest and you might have /blog/current represent the same resource until you post something new. This seems like a valid case in which two different URIs name the same resource. If you…

Hmm, I think that those URLs are still different resources; one is 'the current post' and the other is 'the post named "Why I love REST"'. I would do a 302 from the latter to the former.

Ah, fair enough. They are indeed two different resources. Would you have a problem if I returned the actual representation rather than a 302?

Re: Nobody Understands REST or HTTP

#76

Post by icebraining »

stanleydrew wrote: post #75
icebraining wrote: post #74

Earlier quoted context omitted.

Hmm, I think that those URLs are still different resources; one is 'the current post' and the other is 'the post named "Why I love REST"'. I would do a 302 from the latter to the former.

Ah, fair enough. They are indeed two different resources. Would you have a problem if I returned the actual representation rather than a 302?

I don't have a 'problem' with it, this is just conceptual talk. But I'd still do it for SEO reasons.

If Google fetched /blog/current as containing the "Why I love REST" post and showed it to me, and the when I clicked the link I got "Why I think turtles are awesome", I'd be annoyed. A 302 fixes that in a more clean way than entries in robots.txt or similar tricks.

EDIT: Apparently Google messes that up and often associates the content with the source URL and not the destination URL. Disregard the previous paragraph.

Re: Nobody Understands REST or HTTP

#77

Post by stanleydrew »

icebraining wrote: post #64
decklin wrote: post #31

I don't understand the point of "uri":"/transactions/1". Isn't the new resource's URI already part of the response (in the Location: header)? It's sort of like saying GET /posts/show/1 vs. GET /posts/1.

I agree, it's redundant.

It's redundant in that particular instance. But it's a representation of a resource. It might be nice to define the representation across your entire system so that when you grab a transaction resource with a GET later, it still has that URI in it. Or maybe not. But it's not obvious that this is a bad idea.

Re: Nobody Understands REST or HTTP

#78

Post by noduerme »

wyuenho wrote: post #72

I read the post and I have to say that he's got a nice flamebait title but totally avoided the thorny issues that people argue about. In fact, I'd like to be pointed to a solution for the following problems: 1. I'm an old Web programmer, and my introduction to the Web started with HTML, not HTTP. I don't just write APIs, I write Web apps. I find it difficult to explain to people what this means: If you are religiousl…

It's actually kind of lame that this pompous flamebait makes it to the top of HN, and then he concludes his post saying he doesn't take comments on his blog. excusez-moi, what is he the New Yorker? I'd prefer to address his pomposity on his own turf rather than here, so all I'm going to say is this has all been said before, and it's a bitter irony to spend time talking about flogging dead horses while debating the semantics of a meaningless buzzword with nobody but yourself.

Re: Nobody Understands REST or HTTP

#79

Post by mattgreenrocks »

noduerme wrote: post #78
wyuenho wrote: post #72

I read the post and I have to say that he's got a nice flamebait title but totally avoided the thorny issues that people argue about. In fact, I'd like to be pointed to a solution for the following problems: 1. I'm an old Web programmer, and my introduction to the Web started with HTML, not HTTP. I don't just write APIs, I write Web apps. I find it difficult to explain to people what this means: If you are religiousl…

It's actually kind of lame that this pompous flamebait makes it to the top of HN, and then he concludes his post saying he doesn't take comments on his blog. excusez-moi, what is he the New Yorker? I'd prefer to address his pomposity on his own turf rather than here, so all I'm going to say is this has all been said before, and it's a bitter irony to spend time talking about flogging dead horses while debating the se…

We're getting off-topic, but I don't blame him. A lot of comments are just really bad, and he doesn't want to deal with them.

Re: Nobody Understands REST or HTTP

#80

Post by balakk »

wyuenho wrote: post #72

I read the post and I have to say that he's got a nice flamebait title but totally avoided the thorny issues that people argue about. In fact, I'd like to be pointed to a solution for the following problems: 1. I'm an old Web programmer, and my introduction to the Web started with HTML, not HTTP. I don't just write APIs, I write Web apps. I find it difficult to explain to people what this means: If you are religiousl…

I think you're mixing up multiple things.

- HTTP is a protocol.

- HTML is a markup lanaguage.

- REST is an architectural model for building web services.

They are all different.

> HTTP is not a programming language.. > HTTP statuses > REST is stateless

HTTP is a protocol. A protocol by definition allows certain constructs and prohibits others. There are books available for modeling real-world problems with REST, such as RESTful web services cookbook. I'd suggest going through them, before declaring REST is impractical.

>I'm not sure if I can do it pragmatically in HTTP without getting yelled at

You can certainly use HTTP as you like it, just please don't call it RESTful unless it actually is. A lot of web APIs are not RESTful, nothing wrong with that.

> don't tell me HTTP is the best we can do..

Unfortunately it is for now. Everybody is free to invent their own protocol, write production quality servers to implement it, and get everybody else to adopt it.

Post reply on HN