3 ms·

Part of the problem with these REST discussions is that the definition of what is being discussed keeps shifting. The reasonable bits of REST are, well, reasona

by paul 18y ago

Part of the problem with these REST discussions is that the definition of what is being discussed keeps shifting. The reasonable bits of REST are, well, reasonable, and generally non-controversial. 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.

tlrobinson 18y ago
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 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".
- jsdalton 18y ago
  It's more like a collection or list of resources, and the search term is a filter on that collection.
- bct 18y ago
  > Is www.google.com/search a "resource" or a "method"? You can look at it either way, but it's a perfectly fine resource.
sh1mmer 18y ago
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.
- tlrobinson 18y ago
  "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."
- paul 18y ago
  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).
  - sh1mmer 18y ago
    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.
    - paul 18y ago
      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).
      - bct 18y ago
        > 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.

by paul 18y ago

tlrobinson 18y ago

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 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".

jsdalton 18y ago
It's more like a collection or list of resources, and the search term is a filter on that collection.
bct 18y ago
> Is www.google.com/search a "resource" or a "method"? You can look at it either way, but it's a perfectly fine resource.

sh1mmer 18y ago

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.

tlrobinson 18y ago
"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."
paul 18y ago
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).
- sh1mmer 18y ago
  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.
  - paul 18y ago
    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).
    - bct 18y ago
      > 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.