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

51–60 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#51

Post by jamesaguilar »

manarth wrote: post #48
dewitt wrote: post #38

Earlier quoted context omitted.

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

It wasn't really hyperbole, it was just wrong.

Re: Let's remove verbs from HTTP 2.0

#52

Post by seiji »

jrochkind1 wrote: post #47
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…

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

Re: Let's remove verbs from HTTP 2.0

#53

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

Re: Let's remove verbs from HTTP 2.0

#54

Post by metaphorm »

dragonwriter wrote: post #28
Timmmmbob wrote: post #9

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

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

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.

Re: Let's remove verbs from HTTP 2.0

#55

Post by jscheel »

UnoriginalGuy wrote: post #49
metaphorm wrote: post #45

Earlier quoted context omitted.

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

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.

Re: Let's remove verbs from HTTP 2.0

#56

Post by metaphorm »

UnoriginalGuy wrote: post #49
metaphorm wrote: post #45

Earlier quoted context omitted.

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

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

its all GET and POST. this is typical.

Re: Let's remove verbs from HTTP 2.0

#57

Post by _greim_ »

manarth wrote: post #36
AsymetricCom wrote: post #31

Earlier quoted context omitted.

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

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

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.

Re: Let's remove verbs from HTTP 2.0

#58

Post by bct »

_greim_ wrote: post #37
aeden wrote: post #26

Earlier quoted context omitted.

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?

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

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.

Re: Let's remove verbs from HTTP 2.0

#59

Post by lloeki »

seiji wrote: post #43
manarth wrote: 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…

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

Re: Let's remove verbs from HTTP 2.0

#60

Post by dragonwriter »

metaphorm wrote: post #54
dragonwriter wrote: post #28

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

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.

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

Post reply on HN