Arguing to replace a well-defined single idiom (verbs) with some arbitrary combination of URI, custom headers, request body contents is exactly the opposite of what you want. Using defined verbs instead of having each site do their own slightly different thing makes APIs easier to discover / consume.
> Arguing to replace a well-defined single idiom (verbs) with some arbitrary combination of URI, custom headers, request body contents is exactly the opposite of what you want.
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.
> There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec
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.
Ideally, a REST API would only require consulting the documentation on media types and the ___location of the root endpoint, but the kind of media-type heavy, hyperlink driven driven specification that would support that is rare.
Though specifications aimed at improving at least the hypermedia part of that are starting to gain traction.
I still don't see the value. To me it's like proposing that in SQL we replace 'EXEC' with 'HEAD', 'PUT', 'DELETE'...
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.)
I think the argument was to remove just the unused verbs. I think GET, POST, and HEAD are the ones that make up 99.9% of all use on the web and those are the ones the author thinks should be the only verbs in HTTP.
> 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 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.
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.
Thank you soo much for "Execution in the Kingdom of Nouns". It 's been a while since I cried laughing.
As someone who's been programming in java since 97 (..God I'm old) I certainly saw myself wandering around the Kingdom of Nouns
Also, I feel like "Execution in the Kingdom of Nouns" is semi-relevant here: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...