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

101–110 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#101

Post by seliopou »

fleitz wrote: post #8
neonlex wrote: 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

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.

Re: Let's remove verbs from HTTP 2.0

#102

Post by thezilch »

dragonwriter wrote: post #96
thezilch wrote: post #86

Earlier quoted context omitted.

Huh? DELETE is rarely necessary nor semantic in HTTP. Personally, it's usually more often... -d"status=0" /document/ / Even on an FS, you are more likely semantically switching off its visibility or its fd and not necessarily destroying the underlying bits. The resources are then collected and destroyed at a later and in batch, kept forever in a deactivated state, or written over. And PUT is often a disaster, because…

> Even on an FS, you are more likely semantically switching off its visibility or its fd and not necessarily destroying the underlying bits. The resources are then collected and destroyed at a later and in batch, kept forever in a deactivated state, or written over. So what? All of that is consistent with the semantics of HTTP's DELETE method. From RFC 2616: 9.7 DELETE The DELETE method requests that the origin serve…

Sticking to the article -- not that I'm strictly suggesting DELETE is useless -- the extra verbs confuse the process. POST already covers DELETE, including the response codes. PUT is often more confused. And then PATCH. And then the rabbit hole. That is, DELETE can be semantically correct, but POST would be more so.

Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.

And perhaps I'm talking out of my ass, but the number of DELETE operations is likely vanishingly small for HTTP resources.

Re: Let's remove verbs from HTTP 2.0

#103

Post by dragonwriter »

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

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

Re: Let's remove verbs from HTTP 2.0

#105

Post by pfraze »

sopooneo wrote: post #100
javajosh wrote: post #97

When you think about it, any application can represent every piece of information coming from the outside world in unified data structure. That is, there is no real difference between headers, parameters, and body content (except, of course, in those cases where it is self-referential - for example, when a header tells you how to interpret the rest of the message. But even then one can write a totally generic functio…

Is HEAD really used a lot? I don't know that I've ever used it except to try it once. Is it used in API call? If so, why? Thanks for any help on this.

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 against ditching the extra verbs.

1 http://tools.ietf.org/html/rfc5988

Re: Let's remove verbs from HTTP 2.0

#106

Post by dragonwriter »

thezilch wrote: post #102
dragonwriter wrote: post #96

Earlier quoted context omitted.

> Even on an FS, you are more likely semantically switching off its visibility or its fd and not necessarily destroying the underlying bits. The resources are then collected and destroyed at a later and in batch, kept forever in a deactivated state, or written over. So what? All of that is consistent with the semantics of HTTP's DELETE method. From RFC 2616: 9.7 DELETE The DELETE method requests that the origin serve…

Sticking to the article -- not that I'm strictly suggesting DELETE is useless -- the extra verbs confuse the process. POST already covers DELETE, including the response codes. PUT is often more confused. And then PATCH. And then the rabbit hole. That is, DELETE can be semantically correct, but POST would be more so. Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only…

POST is not idempotent, DELETE is idempotent. That's a pretty significant difference. Yes, obviously, you can use POST in place of DELETE (heck, plenty of APIs have used GET in place of everything), but its not a good idea, and losing DELETE in favor of POST loses clarity.

> That is, DELETE can be semantically correct, but POST would be more so.

DELETE is both more specific about intent and more specific about the idempotence of the operation, so, no, POST would be less semantically correct for any operation where DELETE is semantically correct.

> Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.

Actually, it says that success (2xx) series codes should not be returned unless the server intends to complete the operation, and further specifies that that 200/204 codes indicate that it has enacted the operation (differing in whether a response body is included) and 202 indicates that it has accepted the request but not enacted the operation yet.

Re: Let's remove verbs from HTTP 2.0

#107

Post by rjbond3rd »

sopooneo wrote: post #100
javajosh wrote: post #97

When you think about it, any application can represent every piece of information coming from the outside world in unified data structure. That is, there is no real difference between headers, parameters, and body content (except, of course, in those cases where it is self-referential - for example, when a header tells you how to interpret the rest of the message. But even then one can write a totally generic functio…

Is HEAD really used a lot? I don't know that I've ever used it except to try it once. Is it used in API call? If so, why? Thanks for any help on this.

Yes, it's used a lot. If you look through web server logs, you'll see tons of cases where a search engine spider performs a HEAD, and then based on the headers, it decides whether the content has changed since last fetched. If so, it issues a GET.

Re: Let's remove verbs from HTTP 2.0

#108

Post by dragonwriter »

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.

> I think the argument was to remove just the unused verbs.

What unused verbs?

You know the outcry that got Google to restore CalDAV access to Google Calendar data?

CalDAV adds its own method on top of the whole stack added in WebDAV, as well as borrowing one from the Versioning Extensions to WebDAV (I don't think it actually relies on the whole Versioning Extensions.)

All the HTTP/1.1 verbs (well, except maybe TRACE) -- plus PATCH, plus those in WebDAV, plus many of the extensions to WebDAV (including CalDAV), are all actively used in the wild, on major systems.

I'm no fan of the WebDAV ones, but since its an extension on top of HTTP/1.1, I don't see how HTTP/2.0 could kill them except by forbidding extensions. Which, given the success of Google's attempt to drop CalDAV, I don't see being particularly successful if HTTP/2.0 wants to get widespread adoption (if it doesn't support HTTP/1.1 verbs including extensions, then existing HTTP/1.1 -- and WebDAV extended -- services aren't going to be easy to move over.)

Re: Let's remove verbs from HTTP 2.0

#109

Post by lmz »

pfraze wrote: post #105
sopooneo wrote: post #100

Earlier quoted context omitted.

Is HEAD really used a lot? I don't know that I've ever used it except to try it once. Is it used in API call? If so, why? Thanks for any help on this.

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.

Re: Let's remove verbs from HTTP 2.0

#110

Post by thezilch »

dragonwriter wrote: post #106
thezilch wrote: post #102

Earlier quoted context omitted.

Sticking to the article -- not that I'm strictly suggesting DELETE is useless -- the extra verbs confuse the process. POST already covers DELETE, including the response codes. PUT is often more confused. And then PATCH. And then the rabbit hole. That is, DELETE can be semantically correct, but POST would be more so. Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only…

POST is not idempotent, DELETE is idempotent. That's a pretty significant difference. Yes, obviously, you can use POST in place of DELETE (heck, plenty of APIs have used GET in place of everything ), but its not a good idea, and losing DELETE in favor of POST loses clarity. > That is, DELETE can be semantically correct, but POST would be more so. DELETE is both more specific about intent and more specific about the i…

Idempotent methods are important; I'll give you that. However, the struggle between ACID and CAP theorems would suggest these are just words we will try to live by. I rather dislike having to imagine what it means for my DELETE operation to be bouncing around the network for a minute.

  > unless the server intends to complete the operation
A gerund; it intends to, without any guarantee of recency, to perform the operation. The very same problem that required the operation to be idempotent; it can't be guaranteed the operation is already done, only that it intends to complete in time. A 200 will only describe the status and does not require the description to be "deleted."
Post reply on HN