If the plan as it seems to be now is to completely ruin the good, clean and nice aspects of HTTP, sure, why not?
Add this to the clusterfuck which is HTTP 2.0.
Let's remove verbs from HTTP 2.0
131–140 of 141 posts
Re: Let's remove verbs from HTTP 2.0
#132My first web framework (for newLISP) did this and had a nice visual aid from the Ruby on Rails site that showed why it's a good idea: Simplicity:
http://rundragonfly.com/dragonfly_routes
Search for: "Q: Where are the HTTP verbs GET/POST/PUT?"
Re: Let's remove verbs from HTTP 2.0
#133Arguing 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. Also, I feel like "Execution in the Kingdom of Nouns" is semi-relevant here: http://steve-yegge.blogspot.com/2006/03/e…
> 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 t…
> 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.
Re: Let's remove verbs from HTTP 2.0
#134When you think about it, any application can represent every piece of information coming from the outside world in unified data structure. That is, there is no real difference between headers, parameters, and body content (except, of course, in those cases where it is self-referential - for example, when a header tells you how to interpret the rest of the message. But even then one can write a totally generic functio…
Is HEAD really used a lot? I don't know that I've ever used it except to try it once. Is it used in API call? If so, why? Thanks for any help on this.
Say you have a list of downloads, and you want to know how big they are. With HEAD and Content-Length, you can know, in a standard fashion, assuming the server tells you. Isn't this basic enough, that you'd want to put it in HTTP? What else would you do? Application-specific file-size queries? Doing a GET and then just closing the connection after headers? That's not pretty!
Re: Let's remove verbs from HTTP 2.0
#135Earlier quoted context omitted.
> 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 t…
> 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 on…
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.
Re: Let's remove verbs from HTTP 2.0
#136Earlier quoted context omitted.
> 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 on…
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.
Re: Let's remove verbs from HTTP 2.0
#137Earlier quoted context omitted.
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.
> I still don't see the value.
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.)
Re: Let's remove verbs from HTTP 2.0
#138HTTP/2.0 is meant to have no change to HTTP/1.1 message semantics, and hence its message semantics represent a superset of HTTP/1.1's, so such a change isn't going to happen.
Re: Let's remove verbs from HTTP 2.0
#139If anything, I'd rather have a HTML spec that allows forms to do the other resource oriented verbs.
HTTP and HTML are two different things. If you don't like HTML you are welcome to use a different markup format. This post is all about how the author thinks the other verbs are useless, and they are pretty much useless in the browser. However, HTTP is not just for browsers...
But it seems to me that one of HTTP's prime benefits is its ubiquity. And it's ubiquity is due entirely to its use by browsers.
Re: Let's remove verbs from HTTP 2.0
#140Earlier quoted context omitted.
Is HEAD really used a lot? I don't know that I've ever used it except to try it once. Is it used in API call? If so, why? Thanks for any help on this.
Say you have a list of downloads, and you want to know how big they are. With HEAD and Content-Length, you can know, in a standard fashion, assuming the server tells you. Isn't this basic enough, that you'd want to put it in HTTP? What else would you do? Application-specific file-size queries? Doing a GET and then just closing the connection after headers? That's not pretty!
That makes sense. I was not challenging the inclusion of HEAD in the http verbs, just stating my own ignorance and hoping for illumination, which you and others and have now provided. I appreciate it.