Also, I feel like "Execution in the Kingdom of Nouns" is semi-relevant here: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
It may not be what you want, but it is what you'll get. It's what you'll get now, and in the future. There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec, and that's becoming more true as time goes on. As HTTP APIs become more popular they have become less normalized. It's natural: if you want to expose something, you want to expose it as it is. Not many things adhere to the verb structure of HTTP, I'm not sure anything does unless it was designed to be HTTP from the ground up – which isn't how you should design an API, you should design it to do something useful from the ground up.
I don't even understand why this needs to be pointed out. If the precise usage of all web APIs could be inferred from the verb alone, presumably all web APIs are exactly the same. That's nonsensical. I challenge anybody to honestly claim they have consumed a 3rd party web API of material complexity without once referring to the documentation and solely relying on guessing HTTP verbs.
Once you're already reading the API documentation, I don't understand why you'd prefer "http.request('PUT', '/resource')" over "http.post('/resource/put'). Even better, you can choose a URI that makes the most sense to your domain model, e.g. '/resource/upload'. I don't understand why you'd want to have less expressive URIs AND more work. In even this simple example, the verb is unlikely to be adequate in any case - if you need to supply options or metadata the verb is even less significant as to the true meaning of the operation.
The fact is you can always embed the verb of your choice into the URI - thereby making a GET/POST/HEAD world no more or less expressive than a Verbtopia world. All that extra verbs do is cause consumers of the API to have to remember two pieces of information (VERB + URI) rather than one (URI). At least URIs can be constructed to make as much semantic sense as possible within a given domain model - VERBs, on the other hand, end up as square pegs in round holes, making them far less memorable.
Though specifications aimed at improving at least the hypermedia part of that are starting to gain traction.
At the end of the day I still need to understand the contract of the stored procedure to have any hope of consuming a database API of meaningful complexity.
The value is loose coupling and composability; each media-type is its own contract, and hypermedia provides a common mechanism for discovering the location of endpoints.
This allows different APIs (and their clients) to share common components rather than every large API being a special snowflake.
> To me it's like proposing that in SQL we replace 'EXEC' with 'HEAD', 'PUT', 'DELETE'...
A better SQL equivalent is proposing that you expose to each consumer an appropriate set of relations (likely views) as the application's interface to the database rather than stored procs (the data description of the view is the analog of the media type of the REST resource.)
http://en.wikipedia.org/wiki/Representational_state_transfer...
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.
Spot on.
https://dev.twitter.com/docs/api/1.1
its all GET and POST. this is typical.
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)
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
The discussion of the merits of the verbs aside from their frequency of use in APIs is on other subthreads.
Twitter has no concept of edit for a tweet. Is it surprising then that they don't need to use PUT or PATCH?
I posit that if Netscape had implemented PUT, we'd all be talking about the four main verbs, instead of the three main 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.)
I want some expansion of verbs, counterbalanced with the elimination of some of the less useful verbs.
The focus should be towards forcing webbrowsers away from GET and POST.
OPTIONS should be made mandatory.