Live data from Hacker News

Let's remove verbs from HTTP 2.0

onebigfluke.com

11–20 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#11

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

DELETE /sessions/:id

Re: Let's remove verbs from HTTP 2.0

#12
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.

Re: Let's remove verbs from HTTP 2.0

#13

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

[deleted]

Re: Let's remove verbs from HTTP 2.0

#14
post #7

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

> The real problem is that browsers can't use them as good as they should

That's the obvious inevitability of having too many superfluous options. And one of the main thrusts of the article.

Re: Let's remove verbs from HTTP 2.0

#15
post #11

Earlier quoted context omitted.

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

DELETE /sessions/:id

Except that that is almost never the way you would go about logging someone out. Which is precisely the point.

Re: Let's remove verbs from HTTP 2.0

#17
post #8
post #7

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

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

PUT /myuser/following/theiruser

Re: Let's remove verbs from HTTP 2.0

#18
post #16
post #2

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

...and was a HTML element. Let's not throw out the baby with the bathwater.

It never was. has never, ever, ever been part of the HTML spec or even the HTML drafts. At best, it was an easter egg.

Re: Let's remove verbs from HTTP 2.0

#20
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.
Post reply on HN