Hacker News Reader

Comment by manarth | Hacker News Reader

"Practically speaking there are only two HTTP verbs: read and write, GET and POST."

And thus spoke someone who has never built a REST API, never used curl -I, and probably hasn't used anything other than a web browser to access HTTP content.

Sure, for the most part, we're all kinda new to REST, and we're slowly learning to construct good REST architecture. Sure, there's some redundant weird shit like SPACEJUMP. But we should aim to improve education and encouragement of the use of verbs such as PUT and DELETE, rather than abandon best practice because "no-one's going to use it" or YAGNI, when we can clearly see in talk after expert talk that these are the practices that are being recommended and already put to good use.

Not to mention the plethora of proxies, web servers, and tools that already support these accepted, recognised, standards-defined techniques.

View on HN

"And thus spoke someone who has never built a REST API"

Here are Brett's projects: http://www.onebigfluke.com/

Maybe you've heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.

I'm sorry, I must have missed the <hyperbole> tags.

Yes, the comment is embellished, but the only place where GET and POST are the only verbs is in a basic web browser. Step outside that world, and the other verbs are in use every day…and intermediary devices - with no knowledge of the business logic of the target server - accommodate those verbs, with proper behavior for the most part. Moving those to the URL means that intermediaries cannot disambiguate the intent.

It wasn't really hyperbole, it was just wrong.

Um, I suggest you look up the definition of the word "Hyperbole". I understand that as a Googler, you wish to defend a fellow Googler, but please differentiate between the arguments of "I disagree with the premise of your argument" and "You're wrong". As a Googler, I'd hope you are reasonably technically literate, and therefore could come up with a rather more refined response than "You're just wrong".

Hyperbole means exaggerating something, usually for emphasis or humor. Even taking your comment as hyperbole, the intended, non-exaggerated meaning still appears to be "this person has insufficient experience to speak on this subject." But the person in question is actually very experienced in this area. Given that, I don't think we can blame James if he didn't understand — it's hard to see what the actual meaning behind the statement could have been.

Yeah, I know what hyperbole means. The problem is your comment was not even in the correct direction. Hyperbole is overstating a truth, not strongly stating something false.

And, this guy is a Googler? Who knew? You know your argument is weak when your best responses are "look it up in a dictionary," and "you work for the same company hur hur."

My point about hyperbole was that it's "an extravagant statement or figure of speech not intended to be taken literally". To be fair, I hadn't come across Brett's work before…but anyone writing with degree of detail about HTTP headers, referencing SPACEJUMP and PubSubHubbub has probably used curl -I and may well have worked with a REST API. My point is that the argument - we only use GET and POST - only holds water if we're talking about browsers. although I do see how people could interpret the comment differently, and we all know duty calls: http://xkcd.com/386

"The guy build appengine" isn't a convincing argument either. This is a personal blog, not a peer reviewed journal. Sometimes even distinguished people throw out 270 words without thinking too much about it.

In my mind, two HTTP methods exist: encode things in the URI or encode things in the body of a request.

Go read the RFC definition of PUT and report back. I can never understand it. If anything, PUT needs to be retired in favor of something unambiguously specific like CREATE. In fact, why not go all the way and make all HTTP methods just CREATE, READ, UPDATE, DELETE? That's the only change I (as a nobody) could get behind.

We're not kinda new to REST. REST has formally been around since 2000 and people have been using it heavily since a little before 2008.

Browsers seem to not want to support anything other than GET/POST in forms, so we hack it with running other methods over GET with _method params. Why bother? Just use GET/POST and let the endpoint denote what your intentions are, then have the server side code validate, perform the operations, return results, etc.

(Still rambling: I think one reason REST methods (not URL structure) bother me is it allows lazy (or inexperienced, or incapable) server side programmers to just allow what the client wants. Oh, the client wants to DELETE? Sure. They know what they're doing. No ACL/ownership checks needed). Removing the ability of the client to forcefully say "CREATE/DELETE" may (may) remind the programmer (who is in an outsourced operation in CantProgramistan) they are responsible for the data, not the client asking (asking, not demanding) for operations on the data.)

I my mind, there are only two kids of HTTP transactions: Those that can be repeated over and over safely, and those that can't.

Exactly. REST screws with our internal matrix of "things allowed on methods." Instead of idempotent GET and mutating POST, what does PUT do? Can DELETE be run twice? I'm sure the RFC says, but it just adds additional complexity on our heads (which we may want to override on a per-case basis anyway).

GET is idempotent and safe.

POST and PATCH are neither safe nor idempotent.

PUT and DELETE are idempotent but not safe.

Its not really that complex.

GET alone is safe -- it doesn't have side effects. The results of POST and PATCH depend on the current state of the resource they effect, so they aren't idempotent. The results of DELETE and PUT don't depend on the current state of the resource they target, so they are idempotent.

> I'm sure the RFC says, but it just adds additional complexity on our heads (which we may want to override on a per-case basis anyway).

If you don't want to use the semantics defined in the RFC for a particular method, use the method with the right semantics.

> make all HTTP methods just CREATE, READ, UPDATE, DELETE

No, because resources are not necessarily mapped to database records, nor even behaving like so.

Being able to implement various behaviors in terms of the generic but very well defined HTTP verbs is important, notably PUT being idempotent is extremely useful.

not necessarily mapped to database records

Examples?

nor even behaving like so.

Examples?

Your API could be mapped to a filesystem. (Although you might consider consider a filesystem a database.) If this were the case, it would make sense to use PUT for commands like chown and chmod, which are idempotent. Calling "PUT" "CREATE" here would (IMO) be confusing. I'm not creating something. I'm performing an action, putting things in their proper place, if you will. Another example could be home automation. You might design a REST API where you can PUT cameras to turn them on.

The way I see it, the great thing about HTTP verbs is that they are mostly (not all) unbiased about what they map to, and allow us to be more descriptive. If I'm inspecting the requests my browser is making, I'd much rather see "DELETE /path/to/resource" than see "POST /path/to/resource" and only discover that that call deleted my resource because the body of the request contained '{ "action" : "delete" }'.

Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE. The permissions and owner values already exist by value of the record existing, so of course trying to call CREATE on them seems silly. Same with turning cameras on/off; that's UPDATE on the state on the camera. CREATE would be to add a new camera to the system.

> Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE.

Right, which is why calling PUT to do them "CREATE" would be confusing. But PUT is still the right verb (well, for things like chmod 777; for chmod +X, PATCH would be better.)

PUT isn't "create" its "assign".

> Go read the RFC definition of PUT and report back. I can never understand it. If anything, PUT needs to be retired in favor of something unambiguously specific like CREATE.

PUT is unambiguously defined as "take the request-body, and make it the resource at the given URI". If it was named by the creators of SQL, it would be CREATE OR REPLACE RESOURCE <uri> WITH <request-body>.

(OR, if it was BASIC, it would be "LET <uri> = <request-body>".)

Spoken like someone who has never looked at any of the other stuff that Brett Slatkin has worked on. PubSubHubbub to name just one.

These best part of the post is Tim Bray's response, where he says he would keep PUT and DELETE because they're idempotent, but declined to defend the rest.

Huh? DELETE is rarely necessary nor semantic in HTTP. Personally, it's usually more often...

  -d"status=0" /document/<id>/

Even on an FS, you are more likely semantically switching off its visibility or its fd and not necessarily destroying the underlying bits. The resources are then collected and destroyed at a later and in batch, kept forever in a deactivated state, or written over.

And PUT is often a disaster, because few resources show all its properties in public, and if you're not replacing the resource, is PUT the right semantic?

> Even on an FS, you are more likely semantically switching off its visibility or its fd and not necessarily destroying the underlying bits. The resources are then collected and destroyed at a later and in batch, kept forever in a deactivated state, or written over.

So what? All of that is consistent with the semantics of HTTP's DELETE method. From RFC 2616:

  9.7 DELETE

    The DELETE method requests that the origin server delete 
    the resource identified by the Request-URI. This method 
    MAY be overridden by human intervention (or other means) 
    on the origin server. The client cannot be guaranteed 
    that the operation has been carried out, even if the 
    status code returned from the origin server indicates 
    that the action has been completed successfully. 
    However, the server SHOULD NOT indicate success unless, 
    at the time the response is given, it intends to delete 
    the resource or move it to an inaccessible location.

    A successful response SHOULD be 200 (OK) if the response 
    includes an entity describing the status, 202 (Accepted) 
    if the action has not yet been enacted, or 204 (No    
    Content) if the action has been enacted but the response 
    does not include an entity.

If you are going to say that the semantics of an HTTP method are not right for a particular scenario, there should be something in your description of the scenario that is inconsistent with the semantics of the HTTP method in question.

Sticking to the article -- not that I'm strictly suggesting DELETE is useless -- the extra verbs confuse the process. POST already covers DELETE, including the response codes. PUT is often more confused. And then PATCH. And then the rabbit hole. That is, DELETE can be semantically correct, but POST would be more so.

Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.

And perhaps I'm talking out of my ass, but the number of DELETE operations is likely vanishingly small for HTTP resources.

POST is not idempotent, DELETE is idempotent. That's a pretty significant difference. Yes, obviously, you can use POST in place of DELETE (heck, plenty of APIs have used GET in place of everything), but its not a good idea, and losing DELETE in favor of POST loses clarity.

> That is, DELETE can be semantically correct, but POST would be more so.

DELETE is both more specific about intent and more specific about the idempotence of the operation, so, no, POST would be less semantically correct for any operation where DELETE is semantically correct.

> Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.

Actually, it says that success (2xx) series codes should not be returned unless the server intends to complete the operation, and further specifies that that 200/204 codes indicate that it has enacted the operation (differing in whether a response body is included) and 202 indicates that it has accepted the request but not enacted the operation yet.

Idempotent methods are important; I'll give you that. However, the struggle between ACID and CAP theorems would suggest these are just words we will try to live by. I rather dislike having to imagine what it means for my DELETE operation to be bouncing around the network for a minute.

  > unless the server intends to complete the operation

A gerund; it intends to, without any guarantee of recency, to perform the operation. The very same problem that required the operation to be idempotent; it can't be guaranteed the operation is already done, only that it intends to complete in time. A 200 will only describe the status and does not require the description to be "deleted."

Reply on news.ycombinator.com