Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's remove verbs from HTTP 2.0

onebigfluke.com

Post reply on HN
Print view View original

61–70 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#61

Post by dragonwriter »

Eiwatah4 wrote: post #30
dragonwriter wrote: post #4

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

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

Good point on CONNECT; not something I work with directly, but I'm still embarrassed that I spaced that out.

Re: Let's remove verbs from HTTP 2.0

#62

Post by dragonwriter »

jscheel wrote: post #55
UnoriginalGuy wrote: post #49

Earlier quoted context omitted.

99.9% What? Has nobody on HK ever used REST either as a consumer or producer? http://en.wikipedia.org/wiki/Representational_state_transfer...

Problem is, in a lot of circumstances, you still have to rely on GET and POST with a header like X-REQUEST-METHOD set to tell the server what you really meant.

Usually, this is not the server not supporting it, its a workaround that the server provides so that you can consume the API without AJAX from HTML forms, which are restricted to GET and POST.

EDIT: Although in some cases there is an issue that people choose not to configure it on the web server, and instead use headers or other mechanisms to tunnel the "real" method to the application. But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.

Re: Let's remove verbs from HTTP 2.0

#63

Post by guard-of-terra »

AlexanderDhoore wrote: post #39
generj wrote: post #22

Earlier quoted context omitted.

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

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

He's not only bashing java but writes a lot of java. Are you as comfortable with that?

Re: Let's remove verbs from HTTP 2.0

#64

Post by seiji »

lloeki wrote: post #59
seiji wrote: post #43

Earlier quoted context omitted.

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…

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

not necessarily mapped to database records

Examples?

nor even behaving like so.

Examples?

Re: Let's remove verbs from HTTP 2.0

#66

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

Re: Let's remove verbs from HTTP 2.0

#67

Post by AlexanderDhoore »

guard-of-terra wrote: post #63
AlexanderDhoore wrote: post #39

Earlier quoted context omitted.

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

He's not only bashing java but writes a lot of java. Are you as comfortable with that?

Sure why not. Makes his opinion even more valid. There is a LOT of truth in that essay.

Re: Let's remove verbs from HTTP 2.0

#68

Post by dragonwriter »

seiji wrote: post #52
jrochkind1 wrote: post #47

Earlier quoted context omitted.

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.

Exactly. REST screws with our internal matrix of "things allowed on methods." Instead of idempotent GET and mutating POST, what does PUT do? Can DELETE be run twice? I'm sure the RFC says, but it just adds additional complexity on our heads (which we may want to override on a per-case basis anyway).

GET is idempotent and safe.

POST and PATCH are neither safe nor idempotent.

PUT and DELETE are idempotent but not safe.

Its not really that complex.

GET alone is safe -- it doesn't have side effects. The results of POST and PATCH depend on the current state of the resource they effect, so they aren't idempotent. The results of DELETE and PUT don't depend on the current state of the resource they target, so they are idempotent.

> I'm sure the RFC says, but it just adds additional complexity on our heads (which we may want to override on a per-case basis anyway).

If you don't want to use the semantics defined in the RFC for a particular method, use the method with the right semantics.

Re: Let's remove verbs from HTTP 2.0

#69

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

Re: Let's remove verbs from HTTP 2.0

#70

Post by vampirechicken »

metaphorm wrote: post #45
tl wrote: 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.

GET, POST, and HEAD are the only ones used because since time immemorial, they've been the only ones implemented by the browsers (NN, IE, FF, etc.).

I posit that if Netscape had implemented PUT, we'd all be talking about the four main verbs, instead of the three main verbs.

Post reply on HN