Let's remove verbs from HTTP 2.0
onebigfluke.com
Let's remove verbs from HTTP 2.0
1–10 of 141 posts
Re: Let's remove verbs from HTTP 2.0
#2TIL: I shit you not – SPACEJUMP was once an HTTP verb
Re: Let's remove verbs from HTTP 2.0
#3>PS: It may be worth keeping HEAD just for CORS.
Made me chuckle.
Re: Let's remove verbs from HTTP 2.0
#4I can't agree with the assertion that the methods defined in HTTP since 1.0 are bike-shedding. I'll agree that lots of the the HTTP methods defined in standards other than HTTP are unnecessary cruft (particularly in light of the REST model) -- WebDAV and friends particularly -- but I don't see why you'd want to eliminate any of the HTTP/1.1 verbs (or PATCH) in HTTP/2.0, except maybe replacing HEAD with a no-content media-type in the Accept header for a GET request, and maybe dropping CONNECT and TRACE (though I suspect that there may be cases where they are used and critical, I've just never seen it.)
Re: Let's remove verbs from HTTP 2.0
#5If anything, I'd rather have a HTML spec that allows forms to do the other resource oriented verbs.
Re: Let's remove verbs from HTTP 2.0
#6Removing DELETE and PUT would be a terrible idea, every REST API would break.
Re: Let's remove verbs from HTTP 2.0
#7I also strongly disagree. The real problem is that browsers can't use them as good as they should.
If you take for example a RESTful API, the verbs make totally sense and especially one of the mentioned verbs. PATCH is a great verbs if you use it like it was specified.
I personally like the idea of giving more freedom to chose the verbs.
Imagine you could use for a Twitter API something like:
FOLLOW /users/123
Re: Let's remove verbs from HTTP 2.0
#8I also strongly disagree. The real problem is that browsers can't use them as good as they should. If you take for example a RESTful API, the verbs make totally sense and especially one of the mentioned verbs. PATCH is a great verbs if you use it like it was specified. I personally like the idea of giving more freedom to chose the verbs. Imagine you could use for a Twitter API something like: FOLLOW /users/123
Yes, it would be horrible if you instead had to do:
POST /user/123/follow
Re: Let's remove verbs from HTTP 2.0
#9Removing DELETE and PUT would be a terrible idea, every REST API would break.
I thought someone would say this and I'm afraid it's bullshit. You can just put the REST operations in the URL. This also has the advantage that you aren't artificially restricting yourself to CRUD operations. Some operations do not map to those, e.g. logging out (DELETE user? ... No... DELETE session? I guess?).
I explained in more detail here: http://stackoverflow.com/questions/2191049/what-is-the-advan...
Re: Let's remove verbs from HTTP 2.0
#10Arguing 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/execution-in-kingdom...