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.

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.

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

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

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.

Examples?

nor even behaving like so.

Examples?

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

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

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

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.

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

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?

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.
 

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.

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

  > unless the server intends to complete the operation