
Let's remove verbs from HTTP 2.0 - bslatkin
http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html
======
tl
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.

Also, I feel like "Execution in the Kingdom of Nouns" is semi-relevant here:
[http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

~~~
metaphorm
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.

~~~
UnoriginalGuy
99.9% What? Has nobody on HK ever used REST either as a consumer or producer?

[http://en.wikipedia.org/wiki/Representational_state_transfer...](http://en.wikipedia.org/wiki/Representational_state_transfer#Vocabulary_re-
use_vs._its_arbitrary_extension:_HTTP_and_SOAP)

~~~
metaphorm
sure we have. have you read through the developer docs for most API's? here's
twitters:

[https://dev.twitter.com/docs/api/1.1](https://dev.twitter.com/docs/api/1.1)

its all GET and POST. this is typical.

~~~
YellowRex
I just wrote a REST API for my company and used PUT and DELETE (Tomcat doesn't
support PATCH yet).

Plenty of DELETE in Stripe's API:
[https://stripe.com/docs/api#delete_recipient](https://stripe.com/docs/api#delete_recipient)

Github uses HEAD, PATCH, PUT, and DELETE:
[http://developer.github.com/v3/#http-
verbs](http://developer.github.com/v3/#http-verbs)

Twilio supports PUT and DELETE:
[http://www.twilio.com/docs/api/rest/request](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)

~~~
ramchip
To be fair to the other poster, I wouldn't be surprised if 99.9% _of requests_
were GET/POST/HEAD.

~~~
Gigablah
And 99.9% of requests are GET rather than POST, so shall we get rid of POST
then?

~~~
tericho
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.

~~~
icebraining
You could write and read using just POST. SOAP is the living example of that.
So I think his point is inconsistent.

------
manarth
"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.

~~~
seiji
In my mind, two HTTP methods exist: encode things in the URI or encode things
in the body of a request.

Go read the RFC definition of PUT and report back. I can never understand it.
If anything, PUT needs to be retired in favor of something unambiguously
specific like CREATE. In fact, why not go all the way and make all HTTP
methods just CREATE, READ, UPDATE, DELETE? That's the only change I (as a
nobody) could get behind.

We're not kinda new to REST. REST has formally been around since 2000 and
people have been using it heavily since a little before 2008.

Browsers seem to not want to support anything other than GET/POST in forms, so
we hack it with running other methods over GET with _method params. Why
bother? Just use GET/POST and let the endpoint denote what your intentions
are, then have the server side code validate, perform the operations, return
results, etc.

(Still rambling: I think one reason REST methods (not URL structure) bother me
is it allows lazy (or inexperienced, or incapable) server side programmers to
just allow what the client wants. Oh, the client wants to DELETE? Sure. They
know what they're doing. No ACL/ownership checks needed). Removing the ability
of the client to forcefully say "CREATE/DELETE" may ( _may_ ) remind the
programmer (who is in an outsourced operation in CantProgramistan) they are
responsible for the data, not the client asking (asking, not demanding) for
operations on the data.)

~~~
lloeki
> _make all HTTP methods just CREATE, READ, UPDATE, DELETE_

No, because resources are not necessarily mapped to database records, nor even
behaving like so.

Being able to implement various behaviors in terms of the generic but very
well defined HTTP verbs is important, notably PUT being idempotent is
_extremely_ useful.

~~~
seiji
_not necessarily mapped to database records_

Examples?

 _nor even behaving like so._

Examples?

~~~
argentpyro
Your API could be mapped to a filesystem. (Although you might consider
consider a filesystem a database.) If this were the case, it would make sense
to use PUT for commands like chown and chmod, which are idempotent. Calling
"PUT" "CREATE" here would (IMO) be confusing. I'm not creating something. I'm
performing an action, putting things in their proper place, if you will.
Another example could be home automation. You might design a REST API where
you can PUT cameras to turn them on.

The way I see it, the great thing about HTTP verbs is that they are mostly
(not all) unbiased about what they map to, and allow us to be more
descriptive. If I'm inspecting the requests my browser is making, I'd much
rather see "DELETE /path/to/resource" than see "POST /path/to/resource" and
only discover that that call deleted my resource because the body of the
request contained '{ "action" : "delete" }'.

~~~
jdmichal
Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE. The
permissions and owner values already exist by value of the record existing, so
of course trying to call CREATE on them seems silly. Same with turning cameras
on/off; that's UPDATE on the state on the camera. CREATE would be to add a new
camera to the system.

~~~
dragonwriter
> Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE.

Right, which is why calling PUT to do them "CREATE" would be confusing. But
PUT is still the right verb (well, for things like chmod 777; for chmod +X,
PATCH would be better.)

PUT isn't "create" its "assign".

------
dragonwriter
I 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
CONNECT 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
Good point on CONNECT; not something I work with directly, but I'm still
embarrassed that I spaced that out.

------
stormbrew
There 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
> 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)

------
javajosh
When 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
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.

~~~
pfraze
The 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)

~~~
lmz
Why can't GET support that process? You'd have the extra bytes of the content,
but there's nothing stopping the server sending the Link header in response to
a GET request.

~~~
pfraze
It's already a pretty chatty protocol; if you can support the HEAD request,
why not do so and save the bandwidth?

------
_greim_
While 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
I was thinking something more along the lines of proprietary extensions to
HTML5. Isn't that what everyone's doing now?

~~~
manarth
Don't we stick everything into the body of a JSON object in a GET request
these days?

~~~
_greim_
Sure, 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.

------
lurkinggrue
But I use spacejump to heat my room! It's part of my workflow.

[http://xkcd.com/1172/](http://xkcd.com/1172/)

------
yxhuvud
If anything, I'd rather have a HTML spec that allows forms to do the other
resource oriented verbs.

~~~
aeden
Yes! 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_
My 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
The 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_
Converting "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.

~~~
bct
That would depend on what kind of service you're implementing.

"HTTP/1.1 does not define how a PUT method affects the state of an origin
server."

I don't think it was ever the design or intent of PUT to store the exact
representation that you gave it, and I would be surprised to see evidence
otherwise.

Conceptually it's no different from POSTing (or PUTting) application/json to
produce a resource that will be represented as text/html. How do you convert
JSON to HTML? Depends on the service.

------
bslatkin
TIL: I shit you not – SPACEJUMP was once an HTTP verb

~~~
ghayes
...and <BLINK> was a HTML element. Let's not throw out the baby with the
bathwater.

~~~
Afforess
It 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
And 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.

------
hcarvalhoalves
I'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.

------
mythz
Adding 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
Adding 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.

------
makmanalp
I 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.

------
davewiner
That's why you should be careful about adding concepts because you can't
remove them without breakage.

------
aut0mat0n1c
The 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.

------
aaronbrethorst
Good read, plus I'd never read the email that introduced the bike-shedding
metaphor: [http://white.bikeshed.com](http://white.bikeshed.com)

------
neonlex
I 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

~~~
fleitz
Yes, it would be horrible if you instead had to do: POST /user/123/follow

~~~
jasonkostempski
PUT /myuser/following/theiruser

~~~
manarth
PUT /user/123 { id: 123, following: { foo, bar, baz } }

~~~
icebraining

      PUT /user/123/following
    
        /user/foo
        /user/bar
        http://www.other-site-using-standard-formats.com/user/baz
    

Sigh, if only.

------
manarth
Thinking 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.

------
shawkinaw
Removing DELETE and PUT would be a terrible idea, every REST API would break.

~~~
Timmmmbob
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...](http://stackoverflow.com/questions/2191049/what-is-the-advantage-of-
using-rest-instead-of-non-rest-http/13034235#13034235)

~~~
dragonwriter
> I thought someone would say this and I'm afraid it's bullshit. You can just
> put the REST operations in the URL.

That breaks the basic, clean, clear model of HTTP:

    
    
      URI: specifies the resource against which an action 
        is to be performed
      Method: specifies the action to perform against the 
        resource
    

In favor of a muddy model of:

    
    
      URI: specifies a combination of the resource against
        which an action is to be performed, and some 
        information about the action that is to be performed 
        against the resource
      Method: specifies incomplete information about the 
        action to be performed.
    

Why on Earth would you want to do that?

> This also has the advantage that you aren't artificially restricting
> yourself to CRUD operations.

I'm try to think of an operation in a system that can't be fairly clearly
represented with the semantics of HTTP/1.1 verbs + PATCH, and failing.

> Some operations do not map to those, e.g. logging out (DELETE user? ...
> No... DELETE session? I guess?).

DELETE session is pretty natural. PATCH session to change the status to closed
or, if the session status is its own resource, PUT closed to the status, are
also options.

~~~
metaphorm
DELETE session probably has the wrong semantics for the way most systems
implement sessions and logins. PATCHing it to closed is a better match.
POSTing with the user id to a URL for closing sessions is the best fit for how
we usually do things. There's a reason why most systems are implementing this
with POST instead of PATCH.

~~~
dragonwriter
> DELETE session probably has the wrong semantics for the way most systems
> implement sessions and logins.

I prefer to view HTTP method selection based on the logic from the "user side"
rather than the implementation from the "system side".

Obviously, though, there are different ways of looking at this, and no One
True Way.

------
smartician
Maybe 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
_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._

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.

------
courtneycouch0
I 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.

------
josteink
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.

------
anuraj
It 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.

------
thomasfoster96
Getting 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.

------
gsnedders
HTTP/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.

------
Qantourisc
I'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).

------
coherentpony
>PS: It may be worth keeping HEAD just for CORS.

Made me chuckle.

------
itistoday2
My 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?"

