5 ms·

I thought someone would say this and I'm afraid it's bullshit. You can just put the REST operations in the URL. This also has the advantage that you aren't arti

I thought someone would say this and I'm afraid it's bullshit. You can just put the REST operations in the URL. This also has the advantage that you aren't artificially restricting yourself to CRUD operations. Some operations do not map to those, e.g. logging out (DELETE user? ... No... DELETE session? I guess?). I explained in more detail here: http://stackoverflow.com/questions/2191049/what-is-the-advantage-of-using-rest-instead-of-non-rest-http/13034235#13034235 http://stackoverflow.com/questions/2191049/what-is-the-advan...

mntmn 13y ago
DELETE /sessions/:id
- pbreit 13y ago
  Except that that is almost never the way you would go about logging someone out. Which is precisely the point.
  - deleted 13y ago
    [deleted]
  - daleharvey 13y ago
    This is exactly how I log people out, POST /_session GET /_session DELETE /_session (CouchDB API)
  - dragonwriter 13y ago
    > Except that that is almost never the way you would go about logging someone out. Its the way I would go about logging somebody out. Why wouldn't you?
  - dreamdu5t 13y ago
    That's exactly how I do it. Why wouldn't the session be treated as a resource?
deleted 13y ago
[deleted]
dragonwriter 13y ago
> I thought someone would say this and I'm afraid it's bullshit. You can just put the REST operations in the URL. That breaks the basic, clean, clear model of HTTP: URI: specifies the resource against which an action is to be performed Method: specifies the action to perform against the resource In favor of a muddy model of: URI: specifies a combination of the resource against which an action is to be performed, and some information about the action that is to be performed against the resource Method: specifies incomplete information about the action to be performed. Why on Earth would you want to do that? > This also has the advantage that you aren't artificially restricting yourself to CRUD operations. I'm try to think of an operation in a system that can't be fairly clearly represented with the semantics of HTTP/1.1 verbs + PATCH, and failing. > Some operations do not map to those, e.g. logging out (DELETE user? ... No... DELETE session? I guess?). DELETE session is pretty natural. PATCH session to change the status to closed or, if the session status is its own resource, PUT closed to the status, are also options.
- metaphorm 13y ago
  DELETE session probably has the wrong semantics for the way most systems implement sessions and logins. PATCHing it to closed is a better match. POSTing with the user id to a URL for closing sessions is the best fit for how we usually do things. There's a reason why most systems are implementing this with POST instead of PATCH.
  - dragonwriter 13y ago
    > DELETE session probably has the wrong semantics for the way most systems implement sessions and logins. I prefer to view HTTP method selection based on the logic from the "user side" rather than the implementation from the "system side". Obviously, though, there are different ways of looking at this, and no One True Way.
  - thomasz 13y ago
    > There's a reason why most systems are implementing this with POST instead of PATCH You mean reasons like browsers not supporting anything but POST and GET?
bct 13y ago
It's not an artificial restriction, it's a design constraint that allows the resulting system to have certain properties that are desirable in some circumstances. (And GET/POST/PUT/DELETE isn't CRUD.)
smsm42 13y ago
CRUD doesn't cover the whole world, but it's a good start to cover the most frequent 80%. Saying just because it's not 100% let's make all 100% more complex by removing the unifying principle under it makes no sense.
shawkinaw 13y ago
Well then it's not REST anymore. Your URL should indicate the resource, that's it. Moreover, to say that it's "bullshit" that it would break every REST API is just wrong. That doesn't mean you couldn't change the API to work around it, but it would be broken.

mntmn 13y ago

DELETE /sessions/:id

pbreit 13y ago
Except that that is almost never the way you would go about logging someone out. Which is precisely the point.
- deleted 13y ago
  [deleted]
- daleharvey 13y ago
  This is exactly how I log people out, POST /_session GET /_session DELETE /_session (CouchDB API)
- dragonwriter 13y ago
  > Except that that is almost never the way you would go about logging someone out. Its the way I would go about logging somebody out. Why wouldn't you?
- dreamdu5t 13y ago
  That's exactly how I do it. Why wouldn't the session be treated as a resource?

deleted 13y ago

[deleted]

dragonwriter 13y ago

> I thought someone would say this and I'm afraid it's bullshit. You can just put the REST operations in the URL. That breaks the basic, clean, clear model of HTTP: URI: specifies the resource against which an action is to be performed Method: specifies the action to perform against the resource In favor of a muddy model of: URI: specifies a combination of the resource against which an action is to be performed, and some information about the action that is to be performed against the resource Method: specifies incomplete information about the action to be performed. Why on Earth would you want to do that? > This also has the advantage that you aren't artificially restricting yourself to CRUD operations. I'm try to think of an operation in a system that can't be fairly clearly represented with the semantics of HTTP/1.1 verbs + PATCH, and failing. > Some operations do not map to those, e.g. logging out (DELETE user? ... No... DELETE session? I guess?). DELETE session is pretty natural. PATCH session to change the status to closed or, if the session status is its own resource, PUT closed to the status, are also options.

metaphorm 13y ago
DELETE session probably has the wrong semantics for the way most systems implement sessions and logins. PATCHing it to closed is a better match. POSTing with the user id to a URL for closing sessions is the best fit for how we usually do things. There's a reason why most systems are implementing this with POST instead of PATCH.
- dragonwriter 13y ago
  > DELETE session probably has the wrong semantics for the way most systems implement sessions and logins. I prefer to view HTTP method selection based on the logic from the "user side" rather than the implementation from the "system side". Obviously, though, there are different ways of looking at this, and no One True Way.
- thomasz 13y ago
  > There's a reason why most systems are implementing this with POST instead of PATCH You mean reasons like browsers not supporting anything but POST and GET?

bct 13y ago

It's not an artificial restriction, it's a design constraint that allows the resulting system to have certain properties that are desirable in some circumstances. (And GET/POST/PUT/DELETE isn't CRUD.)

smsm42 13y ago

CRUD doesn't cover the whole world, but it's a good start to cover the most frequent 80%. Saying just because it's not 100% let's make all 100% more complex by removing the unifying principle under it makes no sense.

shawkinaw 13y ago

Well then it's not REST anymore. Your URL should indicate the resource, that's it. Moreover, to say that it's "bullshit" that it would break every REST API is just wrong. That doesn't mean you couldn't change the API to work around it, but it would be broken.