6 ms·

"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,

by manarth 13y ago

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

dewitt 13y ago
"And thus spoke someone who has never built a REST API" Here are Brett's projects: http://www.onebigfluke.com/ http://www.onebigfluke.com/ Maybe you've heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.
- manarth 13y ago
  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.
  - jamesaguilar 13y ago
    It wasn't really hyperbole, it was just wrong.
    - manarth 13y ago
      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".
      - chc 13y ago
        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.
      - jamesaguilar 13y ago
        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."
        manarth 13y ago
        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 http://xkcd.com/386
    - thomasz 13y ago
- kin3tic 13y ago
  Sounds like Brad.
seiji 13y ago
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.)
- jrochkind1 13y ago
  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.
  - seiji 13y ago
    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).
    - dragonwriter 13y ago
      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.
josephscott 13y ago
Spoken like someone who has never looked at any of the other stuff that Brett Slatkin has worked on. PubSubHubbub to name just one.
thezilch 13y ago
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?
- dragonwriter 13y ago
  > 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.
  - thezilch 13y ago
    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.
YellowRex 13y ago
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.

by manarth 13y ago

dewitt 13y ago

"And thus spoke someone who has never built a REST API" Here are Brett's projects: http://www.onebigfluke.com/ http://www.onebigfluke.com/ Maybe you've heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.

manarth 13y ago
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.
- jamesaguilar 13y ago
  It wasn't really hyperbole, it was just wrong.
  - manarth 13y ago
    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".
    - chc 13y ago
      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.
    - jamesaguilar 13y ago
      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."
      - manarth 13y ago
        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 http://xkcd.com/386
  - thomasz 13y ago
kin3tic 13y ago
Sounds like Brad.

seiji 13y ago

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

jrochkind1 13y ago
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.
- seiji 13y ago
  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).
  - dragonwriter 13y ago
    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.

josephscott 13y ago

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

thezilch 13y ago

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?

dragonwriter 13y ago
> 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.
- thezilch 13y ago
  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.

YellowRex 13y ago

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.