11 ms·
Let's remove verbs from HTTP 2.0
- bslatkin 13y agoTIL: I shit you not – SPACEJUMP was once an HTTP verb
- ghayes 13y ago...and <BLINK> was a HTML element. Let's not throw out the baby with the bathwater.
- Afforess 13y agoIt never was. <BLINK> has never, ever, ever been part of the HTML spec or even the HTML drafts. At best, it was an easter egg.
- dragonwriter 13y agoAnd SPACEJUMP has never been part of the HTTP spec. Nor (unlike <BLINK> in HTML) has it been part of HTTP implementations, AFAICT, at least, as an HTTP verb. The "SPACEJUMP" and "TEXTSEARCH" methods appear to be patterns for use of the GET verb.
- coherentpony 13y ago>PS: It may be worth keeping HEAD just for CORS. Made me chuckle.
- dragonwriter 13y agoI 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.)
- Eiwatah4 13y agoCONNECT is used to get a raw socket connection through a HTTP proxy. There'd be no way to get SSL/TLS to work with a proxy without it (save using SOCKS instead of HTTP to talk to the proxy).
- dragonwriter 13y agoGood point on CONNECT; not something I work with directly, but I'm still embarrassed that I spaced that out.
- yxhuvud 13y agoIf anything, I'd rather have a HTML spec that allows forms to do the other resource oriented verbs.
- aeden 13y agoYes! Why is support for PUT and DELETE not specified in HTML specs? Also, why hasn't a browser implementation gone ahead and added support for both of those verbs as an extension beyond the spec?
- _greim_ 13y agoMy understanding is that "PUT" means "make it so that the contents of this request body live at this URL". Meanwhile classic HTML forms only send lists of name/value pairs. So it would have been saying "make it so that this list of name/value pairs lives at this URL" which isn't very useful and would likely have led to widespread creative abuse and corruption of the meaning of "PUT". Likewise, it doesn't make much sense to send a request body with a DELETE, regardless of what it contains. Not forbidden, but not really useful either.
- bct 13y agoThe server can do whatever processing it likes to a PUT's request body. If you upload a PNG it can convert it to a JPEG or an SVG or OCR it or invert the colors, etc. It's perfectly valid to turn application/x-www-form-urlencoded into something else.
- _greim_ 13y agoConverting "image/png" to "image/jpeg" is easy given a knowledge of those formats, but how do you convert "application/x-www-form-urlencoded" to "image/jpeg" or "text/html" or anything else? The only thing you can do is invent your own arbitrary convention, which begins to stray pretty far from the design and intent of PUT.
- 13y ago
- shawkinaw 13y agoRemoving DELETE and PUT would be a terrible idea, every REST API would break.
- Timmmmbob 13y agoI 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-advantage-of-using-rest-instead-of-non-rest-http/13034235#13034235 http://stackoverflow.com/questions/2191049/what-is-the-advan...
- mntmn 13y agoDELETE /sessions/:id
- pbreit 13y agoExcept that that is almost never the way you would go about logging someone out. Which is precisely the point.
- deleted 13y ago[deleted]
- daleharvey 13y agoThis is exactly how I log people out, POST /_session GET /_session DELETE /_session (CouchDB API)
- dragonwriter 13y ago> Except that that is almost never the way you would go about logging someone out. Its the way I would go about logging somebody out. Why wouldn't you?
- 13y ago
- neonlex 13y agoI 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
- smsm42 13y agoJavascript can use them just fine. Browsers without JS can't do a lot of useful things, that's why JS exists.
- fleitz 13y agoYes, it would be horrible if you instead had to do: POST /user/123/follow
- jasonkostempski 13y agoPUT /myuser/following/theiruser
- deleted 13y ago[deleted]
- manarth 13y agoPUT /user/123 { id: 123, following: { foo, bar, baz } }
- icebraining 13y agoPUT /user/123/following /user/foo /user/bar http://www.other-site-using-standard-formats.com/user/baz Sigh, if only.
- seliopou 13y agoYeah, if that's where your URL ended. But what if your URLs kept going? Say you had /user/123/followers or /user/123/followers/followers or /user/123/followers/followers/following ? When your URLs have a non-obvious terminus (as is typical of proper REST APIs) it becomes clear that the verb does not belong in the URL path.
- tl 13y agoArguing 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-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- generj 13y ago"Execution in the Kingdom of Nouns" is excellent. Anyone who hasn't read it should do so immediately. 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.
- AlexanderDhoore 13y agoHadn't read it. Did so immediately. Very good read! God I love it when people hate on java. (I know I shouldn't, but I do.)
- guard-of-terra 13y agoHe's not only bashing java but writes a lot of java. Are you as comfortable with that?
- AlexanderDhoore 13y agoSure why not. Makes his opinion even more valid. There is a LOT of truth in that essay.
- YellowRex 13y agoI write tons of Java in my day job, and at this point it only hurts when I laugh.
- 13y ago
- stormbrew 13y agoThere are two valid reasons I can think of why the verbs need to be specified somewhere for universal agreement: - So that proxies can potentially retry idempotent requests if the upstream fails. Retrying a partially sent GET should be ok, while retrying a partially sent POST is a terrible idea. It's nice in theory, but in practice only reverse proxies at the application endpoint really have the information necessary to make this decision, since many sites have non-idempotent GETs. - Because it affects whether or not there's a request or response body. GETs have no request body but should have a response body. POST/PUT/etc. should have both a request and response body. HEADs have neither a request nor response body. At the moment the only way for an intermediary to know whether a request is finished is because it understands these methods, and this is also true of any extension methods (which is why proxies should generally fail on unknown methods). Mostly it comes down to an issue of routing. And in the end, the ability to have working proxies was an important factor in the popularity of the web imo. But really the first issue is largely moot already and the latter could be fixed in the protocol so that presence or absence of a body could be signalled in the protocol itself (probably is in http2.0 actually). All of that aside, though, http2.0 may never fully replace http1.1. I think there may even be a large portion of the web development community that is hoping it won't. In which case, interop will keep those verbs in place forever.
- Eiwatah4 13y ago> At the moment the only way for an intermediary to know whether a request is finished is because it understands these methods, and this is also true of any extension methods I read the HTTP 1.1 RFC differently. Requests must indicate a body with a Content-Length or Transfer-Encoding header. Responses always have a body (sometimes of length 0), unless it is a response to a HEAD request or has one of a very small number of response codes. http://tools.ietf.org/html/rfc2616#section-4.3 http://tools.ietf.org/html/rfc2616#section-4.3
- meddlepal 13y agoAs I understand it... Only convention is the reason GET does not usually a body. The spec doesn't prevent it.
- _greim_ 13y agoWhile we're at it, let's remove HTTP headers and request bodies, and just stuff everything into the URL. I've written tons of shitty webapps that do exactly that, so it logically follows that we should force everyone to do it.
- AsymetricCom 13y agoI was thinking something more along the lines of proprietary extensions to HTML5. Isn't that what everyone's doing now?
- manarth 13y agoDon't we stick everything into the body of a JSON object in a GET request these days?
- _greim_ 13y agoSure, plenty of people do that, but it's a horrible way to design a web API in my view, and it's definitely not a pattern anybody else should be encouraged to follow.
- icebraining 13y agoYeah, it's SOAP all over again.
- _greim_ 13y agoThe article doesn't present a compelling case for it, though. It points out some quirky aspects of HTTP's history, and concludes "therefore let's remove the verbs" while ignoring the fact that lots of people are literally using the verbs, successfully, right now, and the fact that there's this whole history of SOAP and REST and why having arbitrarily lots of verbs might be a bad thing. It should at least dimly acknowledge those things, before baldly asserting "let's remove the verbs and let people define their own stuff." That's what SOAP did and it failed.
- aaronbrethorst 13y agoGood read, plus I'd never read the email that introduced the bike-shedding metaphor: http://white.bikeshed.com http://white.bikeshed.com
- davewiner 13y agoThat's why you should be careful about adding concepts because you can't remove them without breakage.
- manarth 13y ago"Practically speaking there are only two HTTP verbs: read and write, GET and POST." And thus spoke someone who has never built a REST API, never used curl -I, and probably hasn't used anything other than a web browser to access HTTP content. Sure, for the most part, we're all kinda new to REST, and we're slowly learning to construct good REST architecture. Sure, there's some redundant weird shit like SPACEJUMP. But we should aim to improve education and encouragement of the use of verbs such as PUT and DELETE, rather than abandon best practice because "no-one's going to use it" or YAGNI, when we can clearly see in talk after expert talk that these are the practices that are being recommended and already put to good use. Not to mention the plethora of proxies, web servers, and tools that already support these accepted, recognised, standards-defined techniques.
- dewitt 13y ago"And thus spoke someone who has never built a REST API" Here are Brett's projects: http://www.onebigfluke.com/ http://www.onebigfluke.com/ Maybe you've heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.
- manarth 13y agoI'm sorry, I must have missed the <hyperbole> tags. Yes, the comment is embellished, but the only place where GET and POST are the only verbs is in a basic web browser. Step outside that world, and the other verbs are in use every day…and intermediary devices - with no knowledge of the business logic of the target server - accommodate those verbs, with proper behavior for the most part. Moving those to the URL means that intermediaries cannot disambiguate the intent.
- jamesaguilar 13y agoIt wasn't really hyperbole, it was just wrong.
- manarth 13y agoUm, I suggest you look up the definition of the word "Hyperbole". I understand that as a Googler, you wish to defend a fellow Googler, but please differentiate between the arguments of "I disagree with the premise of your argument" and "You're wrong". As a Googler, I'd hope you are reasonably technically literate, and therefore could come up with a rather more refined response than "You're just wrong".
- mythz 13y agoAdding un-necessary VERBS adds complexity that imposes additional knowledge and burden that increases the surface area that web servers, server software, intermediaries, HTTP Clients, client libraries, browsers, etc need to know in order to support it. What are the call-semantics of the new VERB? Will it be widely used correctly and can we even rely on the spec'ed definition? There's no value adding new VERBs that have the same semantics as POST but just has additional metadata to indicate what the action is. Lessons from WS-* should be not to try add specifications and written unified/concepts for everything but to keep a simple and minimal but flexible specification, that most APIs can operate within.
- jared314 13y agoAdding unnecessary verbs to the standard does create problems, but having a few standard verbs and controlled customization is fantastic. The trouble with custom verbs, like you touched on, is the inability to advertise their contract. I would argue that the OPTIONS verb does not give back enough information to make it useful. Either the OPTIONS verb needs to return more information, or an additional verb should be standardized to allow for discovery and use. The level of specification is a good debate to have, because WS-* was to much specification and REST is almost too little.
- smartician 13y agoMaybe I'm completely off, but in my opinion HTTP verbs are semantically on a lower level. I know that the classic OSI model only has seven layers, and HTTP is in layer seven, but for me, the actual web application using HTTP is in a layer above that. There are side effects to using those verbs that depend on browser and web server used. For example there may be cases where want to use POST instead of GET even for simple data retrieval, just because you're transmitting a credit card number or other sensitive information and you don't want it to be stored in the web server logs or the browser history. Or the parameters might exceed the maximum length for GET requests. In those cases, it would be a pain to make a semantic distinction between the request verbs on the server level. They should be interchangeable. Another example is that in IIS 7 you have to jump through quite a few configuration hoops to get PUT and DELETE to work.
- icebraining 13y agoFor example there may be cases where want to use POST instead of GET even for simple data retrieval, just because you're transmitting a credit card number or other sensitive information and you don't want it to be stored in the web server logs or the browser history. If you're transmitting any information to the server to be processed/stored, sensitive or not, you shouldn't be using GET at all, per the spec. GET params are nice for stuff like filtering and parameterizing the rendering of the representation, but surely a CC number is not adequate for such use cases.
- hcarvalhoalves 13y agoI'm forced to agree. It's pretty much a consensus that the best specs are the smallest ones. You want just the right amount of abstraction to be useful, not try to cover all possible use cases. Inevitably, people will build another layer of abstraction on top.
- manarth 13y agoThinking about it further, it's an interesting question. A typical HTTP system has 3 roles: the client, the intermediaries (proxy/proxies/CDNs/caches), and the application (which combines the server, and any edge devices with knowledge and behaviour that is specific to the application). Currently, the business rules are governed by a complex interrelationship between the request method, request headers, and response headers (including response status). Although request and response bodies may be present, I've not come across any system where the contents of the body affect the business logic of intermediaries. Yes, this could be simplified. But chucking out the request methods is both a low-hanging fruit, but also a short-term saving. Much of the complexity is in the request or response headers (such as Vary), whilst the request method provides a consistent and simple community standard. One of the common limitations I come across is caching of content that varies according to the individual user (or perhaps the role(s) that user has access to within the site). Most web systems send a plethora of cookies - for google analytics, web tracking, advertising, a dozen other things, and eventually for the session. But the proxy-controls that can be sent are limited to "Vary: cookie". This reduces the cache-potential massively. If I were to request one improvement in the HTTP 2 protocol, it would be the ability to vary according to a particular named cookie, rather than the entire cookie header. Oh, and yes, I am aware of the ability to parse the cookie in a proxy, extract the proper key-val params, and vary according to that…but it adds unnecessary complexity to the application, and you can't currently expect uncontrolled downstream proxies to accommodate this practice.
- makmanalp 13y agoI think until we have a way of doing automated service discovery for REST (and OPTIONS is a very lame excuse, knowing what verbs I can use gives me nothing), having 10 bajillion verbs for slightly different semantics doesn't matter. Having a small and standardized set of verbs helps developers, and that's all that matters. And even if we can do automated discovery, what does that really give us? What software is there that automatically crawls unknown APIs, discovers functionality, and then does something useful with it? The semantics of the commands matter, and it's hard to infer that unless you're a human. No amount of HTTP verbs will fix that. For now, good documentation is fine.
- javajosh 13y agoWhen 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 function that does that first pass for you). When modeled this way, there's really not even a useful difference between GET and POST. These days all GETs cause writes to occur anyway, even if they are just analytics. Indeed, I'm constantly surprised that there aren't more "grand unified APIs" for dealing with HTTP. If there were, then we'd have better consensus on just how useless a lot of the HTTP spec has become, verbs included. It reminds me of the Java Servlet API - much of it became worthless with the advent of Struts and SpringMVC, as the front controller pattern better fit the mental model of people writing applications. That said, GET, POST and HEAD are probably worth keeping around, because at least the first two imply something about the kind of idempotency your callers should expect, which is useful.
- sopooneo 13y agoIs 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.
- pfraze 13y agoThe Web Linking RFC [1] uses it to do discovery. The HEAD is mainly used to get ahold of the "Link" response header. > HEAD / HTTP/1.1 < 204 no content < Link: <foobar.com/>; rel="self service"; title="Foobar!", <foobar.com/users>; rel="collection"; id="users" > HEAD /users HTTP/1.1 < 204 no content < Link: <foobar.com/>; rel="up service"; title="Foobar!", <foobar.com/users>; rel="self collection"; id="users" <foobar.com/users/bob>; rel="item"; id="bob" > GET /bob HTTP/1.1 ... GET can't support that process, so that's just one reason why I'm against ditching the extra verbs. 1 http://tools.ietf.org/html/rfc5988 http://tools.ietf.org/html/rfc5988
- 13y ago
- lurkinggrue 13y agoBut I use spacejump to heat my room! It's part of my workflow. http://xkcd.com/1172/ http://xkcd.com/1172/
- thomasfoster96 13y agoGetting rid of the unused verbs would probably save a great deal of confusion. The other alternative is to make it a lot clearer as to what they do and how to use them. But that's not something for the HTTP 2.0 spec.
- aut0mat0n1c 13y agoThe key difference between POST and PUT & DELETE is idempotency. To quote wikipedia "This is a very useful property in many situations, as it means that an operation can be repeated or retried as often as necessary without causing unintended effects. With non-idempotent operations, the algorithm may have to keep track of whether the operation was already performed or not." Read Fielding's dissertation please, or any distributed systems text on the basics of RPC. HTTP is for more than just CRUD websites.
- anuraj 13y agoIt is too late to change HTTP semantics - HTTP has to be backward compatible and when whole host of REST semantics depends on the verbs, it simply not possible to change that. Changing a standard fundamentally is something impossible - rather create a different standard and move slowly there.
- Qantourisc 13y agoI'd say remove some of the old obscure never used words from the standard. And allow ANY custom operation for extensions and custom API (think java-script and programs).
- josteink 13y agoIf 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.
- itistoday2 13y agoMy 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 http://rundragonfly.com/dragonfly_routes Search for: "Q: Where are the HTTP verbs GET/POST/PUT?"
- gsnedders 13y agoHTTP/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.
- courtneycouch0 13y agoI think HEAD is incredibly useful and really critical for things like caching. While you could use GET or POST in place of things like PUT and DELETE, using HTTP headers, you would have to do some work to reap the same benefits you get from HEAD already in retrieving meta data. For implementing things like a CDN, HEAD requests are absolutely critical. Also most developers probably use it with some high frequency using curl.