> I think the argument was to remove just the unused verbs.

What unused verbs?

You know the outcry that got Google to restore CalDAV access to Google Calendar data?

CalDAV adds its own method on top of the whole stack added in WebDAV, as well as borrowing one from the Versioning Extensions to WebDAV (I don't think it actually relies on the whole Versioning Extensions.)

All the HTTP/1.1 verbs (well, except maybe TRACE) -- plus PATCH, plus those in WebDAV, plus many of the extensions to WebDAV (including CalDAV), are all actively used in the wild, on major systems.

I'm no fan of the WebDAV ones, but since its an extension on top of HTTP/1.1, I don't see how HTTP/2.0 could kill them except by forbidding extensions. Which, given the success of Google's attempt to drop CalDAV, I don't see being particularly successful if HTTP/2.0 wants to get widespread adoption (if it doesn't support HTTP/1.1 verbs including extensions, then existing HTTP/1.1 -- and WebDAV extended -- services aren't going to be easy to move over.)

GET, POST, and HEAD are the only ones used because since time immemorial, they've been the only ones implemented by the browsers (NN, IE, FF, etc.).

I posit that if Netscape had implemented PUT, we'd all be talking about the four main verbs, instead of the three main verbs.

99.9% What? Has nobody on HK ever used REST either as a consumer or producer?

http://en.wikipedia.org/wiki/Representational_state_transfer...

sure we have. have you read through the developer docs for most API's? here's twitters:

https://dev.twitter.com/docs/api/1.1

its all GET and POST. this is typical.

I just wrote a REST API for my company and used PUT and DELETE (Tomcat doesn't support PATCH yet).

Plenty of DELETE in Stripe's API: https://stripe.com/docs/api#delete_recipient

Github uses HEAD, PATCH, PUT, and DELETE: http://developer.github.com/v3/#http-verbs

Twilio supports PUT and DELETE: http://www.twilio.com/docs/api/rest/request

There are all darlings of the HK community with highly praised, widely used REST APIs. Have you read through the developer docs for most APIs?

(edit: typo)

To be fair to the other poster, I wouldn't be surprised if 99.9% of requests were GET/POST/HEAD.

And 99.9% of requests are GET rather than POST, so shall we get rid of POST then?

GET and POST already have widely observed distinctions in how they should be handled. For example, try hitting refresh on a page that was arrived at via a POST request. That behaviour is pretty much common to all browsers.

His point was that at minimum you still need a GET and POST for read and write. So comparing the numbers against bike-shed implementations is moot. Of course the number of reads will be significantly higher.

You could write and read using just POST. SOAP is the living example of that. So I think his point is inconsistent.

Okay, here's Google Drive's

https://developers.google.com/drive/v2/reference/

it uses GET, POST, PATCH, PUT, and DELETE

Here's (part of) the Amazon S3 API:

http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketOps... http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectOps...

HEAD, GET, DELETE, PUT, POST

And that makes the API better because...?

I'm responding here to the claim that the verbs other than GET, HEAD, and POST are generally unused in APIs.

The discussion of the merits of the verbs aside from their frequency of use in APIs is on other subthreads.

That's Twitters'.

Twitter has no concept of edit for a tweet. Is it surprising then that they don't need to use PUT or PATCH?

Problem is, in a lot of circumstances, you still have to rely on GET and POST with a header like X-REQUEST-METHOD set to tell the server what you really meant.

Usually, this is not the server not supporting it, its a workaround that the server provides so that you can consume the API without AJAX from HTML forms, which are restricted to GET and POST.

EDIT: Although in some cases there is an issue that people choose not to configure it on the web server, and instead use headers or other mechanisms to tunnel the "real" method to the application. But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.

“But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.”

Spot on.