3 ms·

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 jus

by 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.
  - sh1mmer 18y ago
    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.

by paul 18y ago

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.
- sh1mmer 18y ago
  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.