What makes a system RESTful or not isn't so much the verb it uses, but the fact the interactions are driven by the hypermedia (in this case, this includes code-on-demand JavaScript).
The GET/PUT/POST/DELETE mapping you're quoting works fine for CRUD operations, but isn't necessarily appropriate for everything (and isn't necessarily supported by all browsers). This is a reasonable rule of thumb to design a RESTful system, but it's neither sufficient nor necessary. (It's in the same category of ideas as what people insist on when they want "RESTful" URIs: there's no such thing.)
Part of this comes under influence of books like RESTful Web Services. It's a good book, but it came out at a time where WS-*/SOAP was predominant, and where everything was tunnelled through POST. A reaction to SOAP was to make people aware that there were other HTTP verbs they could use.
For REST, what really matters in particular is to respect the notions behind the URI concept, the semantics of each HTTP verb (no side-effects, idempotent requests, ..., where appropriate and if you're using HTTP) and the HATEOS principle. It's an architectural style, don't stress too much about what POST/PUT/DELETE the JavaScript does underneath.
You should certainly read these:
EDIT: (Following comments)
What I should have said was this: If most frameworks turn DELETE
http://server.tld/resource/1
into POST
http://server.tld/resource/1?_method=DELETE
, then what's the advantage
of that approach over just using POST
http://server.tld/resource/1?my_method=delete
in the first place?
- It makes the overall goal a little bit cleaner/clearer, in terms of API design. REST frameworks can ultimately only be as RESTful as one uses them, since REST is an architectural style, not a protocol or an implementation.
- In addition, strictly speaking, the URI includes the query component, so
http://server.tld/resource/1
and http://server.tld/resource/1?my_method=DELETE
could identify different resources in principle (although that wouldn't be a good design choice).
It's good for the framework to be able to expose DELETE
/PUT
as such directly, but have a fallback solution via POST
for the clients that don't support it.
The reason for this is that clients that do support DELETE
/PUT
will be able to make use of them, and make assumptions about their usage. It's not so much of a problem for the client to treat a request as non-idempotent even if it was idempotent in principle as the opposite. If the client thinks it can send at most 1 request (non-idempotent) when it could have sent N+1 of the requests, this doesn't cause major problems; if the client thinks it can send N+1 times the same request for something that shouldn't be idempotent, this can cause quite a lot of problems. Emulating PUT
through POST
is OK, you're just not making the most of PUT
, emulating POST
through PUT
would be problematic.