Hacker News Reader

Comment by Timmmmbob | Hacker News Reader

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

View on HN

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

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.

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

> 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?

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.

DELETE /sessions/:id

Except that that is almost never the way you would go about logging someone out. Which is precisely the point.

This is exactly how I log people out,

POST /_session GET /_session DELETE /_session

(CouchDB API)

> 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?

That's exactly how I do it. Why wouldn't the session be treated as a resource?

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.

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

Reply on news.ycombinator.com