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

111–120 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#111

Post by lucisferre »

dragonwriter wrote: post #103
metaphorm wrote: post #56

Earlier quoted context omitted.

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.

Okay, here's Google Drive's https://developers.google.com/drive/v2/reference/ it uses GET, POST, PATCH, PUT, and DELETE Here's (part of) the Amazon S3 API: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketOps... http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectOps... HEAD, GET, DELETE, PUT, POST

And that makes the API better because...?

Re: Let's remove verbs from HTTP 2.0

#112

Post by pfraze »

lmz wrote: post #109
pfraze wrote: post #105

Earlier quoted context omitted.

The Web Linking RFC [1] uses it to do discovery. The HEAD is mainly used to get ahold of the "Link" response header. > HEAD / HTTP/1.1 ; rel="self service"; title="Foobar!", ; rel="collection"; id="users" > HEAD /users HTTP/1.1 ; rel="up service"; title="Foobar!", ; rel="self collection"; id="users" ; rel="item"; id="bob" > GET /bob HTTP/1.1 ... GET can't support that process, so that's just one reason why I'm agains…

Why can't GET support that process? You'd have the extra bytes of the content, but there's nothing stopping the server sending the Link header in response to a GET request.

It's already a pretty chatty protocol; if you can support the HEAD request, why not do so and save the bandwidth?

Re: Let's remove verbs from HTTP 2.0

#113

Post by dragonwriter »

lucisferre wrote: post #111
dragonwriter wrote: post #103

Earlier quoted context omitted.

Okay, here's Google Drive's https://developers.google.com/drive/v2/reference/ it uses GET, POST, PATCH, PUT, and DELETE Here's (part of) the Amazon S3 API: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketOps... http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectOps... HEAD, GET, DELETE, PUT, POST

And that makes the API better because...?

I'm responding here to the claim that the verbs other than GET, HEAD, and POST are generally unused in APIs.

The discussion of the merits of the verbs aside from their frequency of use in APIs is on other subthreads.

Re: Let's remove verbs from HTTP 2.0

#114

Post by Gigablah »

ramchip wrote: post #94
YellowRex wrote: post #88

Earlier quoted context omitted.

I just wrote a REST API for my company and used PUT and DELETE (Tomcat doesn't support PATCH yet). Plenty of DELETE in Stripe's API: https://stripe.com/docs/api#delete_recipient Github uses HEAD, PATCH, PUT, and DELETE: http://developer.github.com/v3/#http-verbs Twilio supports PUT and DELETE: http://www.twilio.com/docs/api/rest/request There are all darlings of the HK community with highly praised, widely used REST…

To be fair to the other poster, I wouldn't be surprised if 99.9% of requests were GET/POST/HEAD.

And 99.9% of requests are GET rather than POST, so shall we get rid of POST then?

Re: Let's remove verbs from HTTP 2.0

#115

Post by aut0mat0n1c »

The key difference between POST and PUT & DELETE is idempotency. To quote wikipedia "This is a very useful property in many situations, as it means that an operation can be repeated or retried as often as necessary without causing unintended effects. With non-idempotent operations, the algorithm may have to keep track of whether the operation was already performed or not."

Read Fielding's dissertation please, or any distributed systems text on the basics of RPC. HTTP is for more than just CRUD websites.

Re: Let's remove verbs from HTTP 2.0

#116

Post by shawnz »

Gigablah wrote: post #114
ramchip wrote: post #94

Earlier quoted context omitted.

To be fair to the other poster, I wouldn't be surprised if 99.9% of requests were GET/POST/HEAD.

And 99.9% of requests are GET rather than POST, so shall we get rid of POST then?

GET and POST already have widely observed distinctions in how they should be handled. For example, try hitting refresh on a page that was arrived at via a POST request. That behaviour is pretty much common to all browsers.

Re: Let's remove verbs from HTTP 2.0

#117

Post by danabramov »

dragonwriter wrote: post #62
jscheel wrote: post #55

Earlier quoted context omitted.

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…

“But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.”

Spot on.

Re: Let's remove verbs from HTTP 2.0

#118

Post by thomasz »

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.

"The guy build appengine" isn't a convincing argument either. This is a personal blog, not a peer reviewed journal. Sometimes even distinguished people throw out 270 words without thinking too much about it.

Re: Let's remove verbs from HTTP 2.0

#119

Post by fleitz »

seliopou wrote: post #101
fleitz wrote: post #8

Earlier quoted context omitted.

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

Yeah, if that's where your URL ended. But what if your URLs kept going? Say you had /user/123/followers or /user/123/followers/followers or /user/123/followers/followers/following ? When your URLs have a non-obvious terminus (as is typical of proper REST APIs) it becomes clear that the verb does not belong in the URL path.

So you're saying that we should have a verb instead?

FOLLOWERS_FOLLOWERS_FOLLOWING /user/123

Re: Let's remove verbs from HTTP 2.0

#120

Post by meddlepal »

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

As I understand it... Only convention is the reason GET does not usually a body. The spec doesn't prevent it.
Post reply on HN