Live data from Hacker News

Let's remove verbs from HTTP 2.0

onebigfluke.com

41–50 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#41
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

Javascript can use them just fine. Browsers without JS can't do a lot of useful things, that's why JS exists.

Re: Let's remove verbs from HTTP 2.0

#42

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

CRUD doesn't cover the whole world, but it's a good start to cover the most frequent 80%. Saying just because it's not 100% let's make all 100% more complex by removing the unifying principle under it makes no sense.

Re: Let's remove verbs from HTTP 2.0

#43
post #35

"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 w…

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

Re: Let's remove verbs from HTTP 2.0

#44
post #35

"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 w…

Spoken like someone who has never looked at any of the other stuff that Brett Slatkin has worked on. PubSubHubbub to name just one.

Re: Let's remove verbs from HTTP 2.0

#45
post #10

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/e…

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.

Re: Let's remove verbs from HTTP 2.0

#46
post #15
post #11

Earlier quoted context omitted.

DELETE /sessions/:id

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

That's exactly how I do it. Why wouldn't the session be treated as a resource?

Re: Let's remove verbs from HTTP 2.0

#47
post #43
post #35

"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 w…

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 b…

I my mind, there are only two kids of HTTP transactions: Those that can be repeated over and over safely, and those that can't.

Re: Let's remove verbs from HTTP 2.0

#48
post #38
post #35

"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 w…

"And thus spoke someone who has never built a REST API" Here are Brett's projects: http://www.onebigfluke.com/ Maybe you've heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.

I'm sorry, I must have missed the 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.

Re: Let's remove verbs from HTTP 2.0

#49
post #10

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/e…

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.

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

http://en.wikipedia.org/wiki/Representational_state_transfer...

Re: Let's remove verbs from HTTP 2.0

#50
post #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.

I was thinking something more along the lines of proprietary extensions to HTML5. Isn't that what everyone's doing now?

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