Explaining REST to Damien Katz(25hoursaday.com)
25hoursaday.com
Explaining REST to Damien Katz
http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
4 comments
Agreed. I think there's a couple issues that cause confusion.
Yes, REST advocates say your URLs should be for "resources" not "methods", but sometimes the distinction is blurry. For example, a Google search: http://www.google.com/search?q=restful
Is www.google.com/search a "resource" or a "method"? I would call it a method, but it's also sort of a resource. I can't think of any way to make it more "resource oriented".
Yes, REST advocates say your URLs should be for "resources" not "methods", but sometimes the distinction is blurry. For example, a Google search: http://www.google.com/search?q=restful
Is www.google.com/search a "resource" or a "method"? I would call it a method, but it's also sort of a resource. I can't think of any way to make it more "resource oriented".
Well yes, that is sort of true. But, if it were most other subjects people wouldn't give a crap. It's hard to say what it is about pure REST that works people up so much.
I think, perhaps, it's hard for people to be told they don't get REST when they thought they did but were actually doing a REST-RPC hybrid.
I think, perhaps, it's hard for people to be told they don't get REST when they thought they did but were actually doing a REST-RPC hybrid.
The thing is, there's nothing wrong with doing REST-RPC hybrid. The reasonable parts of REST (like making things stateless, using http error codes, etc) are just as reasonable with RPC, and often RPC is the right way to approach an API (better than pure REST).
But you don't get benefits like addressability and caching.
REST advocates have been repeatedly been accused of being religious, but I'm citing reasons you are just saying "and often RPC is the right way to approach an API (better than pure REST)". Which gives meaning to rightness at all.
The "religion" in this debate has nothing to do with any style of architecture, it's simply the rigour people choose to put in to their arguments.
I won't support a bad argument for REST any more than I'll support a bad one for anything else.
REST advocates have been repeatedly been accused of being religious, but I'm citing reasons you are just saying "and often RPC is the right way to approach an API (better than pure REST)". Which gives meaning to rightness at all.
The "religion" in this debate has nothing to do with any style of architecture, it's simply the rigour people choose to put in to their arguments.
I won't support a bad argument for REST any more than I'll support a bad one for anything else.
The GET side of REST is usually reasonable and non-controversial. It's the other verbs where things get crazy, with people arguing that you should PUT comments to a document instead of doing a POST to /addcomment (because add comment is a verb). I gave some examples on the other thread showing how the supposed caching benefits are largely imaginary (beyond simple GET caching), and simple RPC is easier to deal with (because you aren't limiting yourself to 5 verbs).
Paul, you've obviously built some great services. I'm absolutely not going to try and argue that you don't know how to build an API.
However, I don't agree with you on this point, and I'm happy to leave it there. Luckily, I get to work with people like Mark Nottingham, and I'm confident in my points regarding caching.
Doing it RESTfully doesn't loose you anything regarding caching and suddenly you are able to address everything. Personally, I think that's pretty cool.
However, I don't agree with you on this point, and I'm happy to leave it there. Luckily, I get to work with people like Mark Nottingham, and I'm confident in my points regarding caching.
Doing it RESTfully doesn't loose you anything regarding caching and suddenly you are able to address everything. Personally, I think that's pretty cool.
> with people arguing that you should PUT comments to a document instead of doing a POST to /addcomment (because add comment is a verb).
If people are arguing that, then they don't grok REST (or HTTP verbs, for that matter).
But tell me, why would it be better to POST to /addcomment than to POST to /comments ?
Edit: Or is your point just that some people misapply REST? There's nothing surprising about that.
If people are arguing that, then they don't grok REST (or HTTP verbs, for that matter).
But tell me, why would it be better to POST to /addcomment than to POST to /comments ?
Edit: Or is your point just that some people misapply REST? There's nothing surprising about that.
/addcomment v.s. /comment is all about the relationship to the parent. /addcomment IMHO should be a PUT since you're telling me your updating the parent, whereas /comments makes sense as a POST.
Just my two cents, but I'm not a fan of a POST with /add. POST already says create. PUT says update. /add is wasteful and confusing when you already grok HTTP verbs.
If you don't really think in terms of HTTP verbs though, then /add reduces confusion. The more uptake REST gets, the more natural it'll seem.
Just my two cents, but I'm not a fan of a POST with /add. POST already says create. PUT says update. /add is wasteful and confusing when you already grok HTTP verbs.
If you don't really think in terms of HTTP verbs though, then /add reduces confusion. The more uptake REST gets, the more natural it'll seem.
> why would it be better to POST to /addcomment than to POST to /comments ?
Er, paul actually said PUT to the document (with no particular URI given). POSTing to /comments vs. /addcomment is pretty much a moot point, but I think I agree that "PUT to the document" to add a comment is the wrong thing to do. PUT implies overwriting and should be idempotent. It seems to make sense for _editing_ comments, but the only way I could think of to create a comment that way is to have the client PUT the comment with a GUID. Which seems rather icky: do you want GUIDs messing up your pretty URI space with strings of junk?
Er, paul actually said PUT to the document (with no particular URI given). POSTing to /comments vs. /addcomment is pretty much a moot point, but I think I agree that "PUT to the document" to add a comment is the wrong thing to do. PUT implies overwriting and should be idempotent. It seems to make sense for _editing_ comments, but the only way I could think of to create a comment that way is to have the client PUT the comment with a GUID. Which seems rather icky: do you want GUIDs messing up your pretty URI space with strings of junk?
Comments in this case would be a resource which is a container (of all comments)
Posting to the container therefore makes sense as it's equivalent to a factory method to make a child of the container.
Posting to the container therefore makes sense as it's equivalent to a factory method to make a child of the container.
I agree, which is why I said that people advocating PUT for commenting don't grok HTTP verbs. (I've never seen anybody advocate that.)
"It's hard to say what it is about pure REST that works people up so much."
I think a comment on Damien's blog summed it up nicely:
"I love living in the modern age.
It's so refreshing to have moved from religious fights based on the Bible to religious fights based on RFCs."
I think a comment on Damien's blog summed it up nicely:
"I love living in the modern age.
It's so refreshing to have moved from religious fights based on the Bible to religious fights based on RFCs."
Apropos nothing, Dare Obasanjo needs to seriously reconsider the use of boldface as his link style.
I think that Damien's point is that he doesn't get the "self-evidence" or Good Thinginess of using REST as a _developer_ of a web application. I see it over and over again in development situations: As soon as the topic of webservices comes up, someone starts crying, "REST! REST! OMG, REST!" And that's usually before they've even heard what the web service will do.
It's funny: When REST advocates are pressed about how REST might not be the best choice for every, single development effort, they either:
1. Simply regurgitate REST's tenants 2. Deny that they are regurgitating REST's tenants, and then go on to regurgitate REST's tenants
I think that everyone can acknowledge the good of using REST as a _user_ of a web application -- which is what the REST literature addresses anyway. But is REST going help app developers deliver features in a timely manner? Is it the most agile way to develop? Not necessarily.
<controversial>If you follow REST to its purist implications, you probably wouldn't have a dynamic web application at all. Instead, you'd have a interlinked mesh of of hand-written HTML pages that cover every representation of the application. Hello, Early Web!</controversial>
So anyway, if REST works for you, awesome; as long as you've designed your resources and interfaces intelligibly, you're helping to make the waters of the internet easier to navigate. It SOAP/RPC isn't working for you, maybe you should try REST. But if SOAP/RPC is serving you just fine, don't let this topic rock your boat.
It's funny: When REST advocates are pressed about how REST might not be the best choice for every, single development effort, they either:
1. Simply regurgitate REST's tenants 2. Deny that they are regurgitating REST's tenants, and then go on to regurgitate REST's tenants
I think that everyone can acknowledge the good of using REST as a _user_ of a web application -- which is what the REST literature addresses anyway. But is REST going help app developers deliver features in a timely manner? Is it the most agile way to develop? Not necessarily.
<controversial>If you follow REST to its purist implications, you probably wouldn't have a dynamic web application at all. Instead, you'd have a interlinked mesh of of hand-written HTML pages that cover every representation of the application. Hello, Early Web!</controversial>
So anyway, if REST works for you, awesome; as long as you've designed your resources and interfaces intelligibly, you're helping to make the waters of the internet easier to navigate. It SOAP/RPC isn't working for you, maybe you should try REST. But if SOAP/RPC is serving you just fine, don't let this topic rock your boat.
For the record, Dave Winer didn't come up with SOAP, and didn't do with a "bunch of folks from Microsoft". SOAP sucks and it's largely due to MS' influence, but Winer merely came up with XML-RPC, which is pretty close to Damien's idea that maybe POST is enough.
Not that I'm a Winer fan -- his behavior oddly reflects his surname -- but facts is facts. Dave understands the need for simplicity, and needless to say, the SOAP folks don't.
Not that I'm a Winer fan -- his behavior oddly reflects his surname -- but facts is facts. Dave understands the need for simplicity, and needless to say, the SOAP folks don't.
Most of what he describes in this post is fairly reasonable, but his previous REST post (that I mentioned as silly) focused on the less reasonable (and more dogmatic) parts. He criticized APIs for such things as, "REST API Sin #1: URIs Identify Methods Instead of Resources (The Original Sin)". Referring to design decisions as "sins" may be cute, but it's also a clue that you may be drifting away from pragmatism and towards religion.