3 ms·

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 u

by 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.
      - sapphirecat 18y ago
        > 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?
        bct 18y ago
        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.)
        sh1mmer 18y ago
        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.
      - rapind 18y ago
        /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.

by sh1mmer 18y ago

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.
    - sapphirecat 18y ago
      > 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?
      - bct 18y ago
        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.)
      - sh1mmer 18y ago
        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.
    - rapind 18y ago
      /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.