2 ms·

> 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

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

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.