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

71–80 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#71

Post by dragonwriter »

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…

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

PUT is unambiguously defined as "take the request-body, and make it the resource at the given URI". If it was named by the creators of SQL, it would be CREATE OR REPLACE RESOURCE WITH .

(OR, if it was BASIC, it would be "LET = ".)

Re: Let's remove verbs from HTTP 2.0

#72

Post by kin3tic »

dewitt wrote: post #38
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…

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

Sounds like Brad.

Re: Let's remove verbs from HTTP 2.0

#73

Post by dragonwriter »

aeden wrote: post #26
yxhuvud wrote: post #5

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

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?

> Yes! Why is support for PUT and DELETE not specified in HTML specs?

IIRC, it was in an earlier draft of the WHATWG HTML spec, was implemented in a beta version of Firefox, issues were raised with the semantics of the Firefox implementation that ended up becoming issues with the clarity of what browsers were supposed to do with PUT/DELETE forms in the draft HTML spec, and the result was taking PUT/DELETE support out of the spec because of the lack of agreement on what should be specified regarding the use of those methods with forms.

ISTR that this issue has been reopened as a bug with the spec since that time, though I don't know if it is currently open or not.

Re: Let's remove verbs from HTTP 2.0

#74

Post by _greim_ »

bct wrote: post #58
_greim_ wrote: post #37

Earlier quoted context omitted.

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.

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.

Re: Let's remove verbs from HTTP 2.0

#75

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

Re: Let's remove verbs from HTTP 2.0

#76

Post by bct »

_greim_ wrote: post #74
bct wrote: post #58

Earlier quoted context omitted.

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.

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.

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.

Re: Let's remove verbs from HTTP 2.0

#77

Post by jared314 »

mythz wrote: post #53

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

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.

Re: Let's remove verbs from HTTP 2.0

#78

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

Re: Let's remove verbs from HTTP 2.0

#79

Post by shawkinaw »

Timmmmbob wrote: post #9
shawkinaw wrote: post #6

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

Well then it's not REST anymore. Your URL should indicate the resource, that's it. Moreover, to say that it's "bullshit" that it would break every REST API is just wrong. That doesn't mean you couldn't change the API to work around it, but it would be broken.

Re: Let's remove verbs from HTTP 2.0

#80

Post by manarth »

jamesaguilar wrote: post #51
manarth wrote: post #48

Earlier quoted context omitted.

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.

Um, I suggest you look up the definition of the word "Hyperbole". I understand that as a Googler, you wish to defend a fellow Googler, but please differentiate between the arguments of "I disagree with the premise of your argument" and "You're wrong". As a Googler, I'd hope you are reasonably technically literate, and therefore could come up with a rather more refined response than "You're just wrong".
Post reply on HN