It is too late to change HTTP semantics - HTTP has to be backward compatible and when whole host of REST semantics depends on the verbs, it simply not possible to change that. Changing a standard fundamentally is something impossible - rather create a different standard and move slowly there.
Let's remove verbs from HTTP 2.0
121–130 of 141 posts
Re: Let's remove verbs from HTTP 2.0
#122Earlier 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.
> There's a reason why most systems are implementing this with POST instead of PATCH
You mean reasons like browsers not supporting anything but POST and GET?
Re: Let's remove verbs from HTTP 2.0
#123Earlier quoted context omitted.
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".
Yeah, I know what hyperbole means. The problem is your comment was not even in the correct direction. Hyperbole is overstating a truth, not strongly stating something false.
And, this guy is a Googler? Who knew? You know your argument is weak when your best responses are "look it up in a dictionary," and "you work for the same company hur hur."
Re: Let's remove verbs from HTTP 2.0
#124When 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.
personally I use HEAD quite often in the form of `curl -I` if I want to check the size or mime type of a particular resource.
Re: Let's remove verbs from HTTP 2.0
#125Earlier 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?
His point was that at minimum you still need a GET and POST for read and write. So comparing the numbers against bike-shed implementations is moot. Of course the number of reads will be significantly higher.
Re: Let's remove verbs from HTTP 2.0
#126Earlier quoted context omitted.
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".
Yeah, I know what hyperbole means. The problem is your comment was not even in the correct direction. Hyperbole is overstating a truth, not strongly stating something false. And, this guy is a Googler? Who knew? You know your argument is weak when your best responses are "look it up in a dictionary," and "you work for the same company hur hur."
My point about hyperbole was that it's "an extravagant statement or figure of speech not intended to be taken literally". To be fair, I hadn't come across Brett's work before…but anyone writing with degree of detail about HTTP headers, referencing SPACEJUMP and PubSubHubbub has probably used curl -I and may well have worked with a REST API. My point is that the argument - we only use GET and POST - only holds water if we're talking about browsers. although I do see how people could interpret the comment differently, and we all know duty calls: http://xkcd.com/386
Re: Let's remove verbs from HTTP 2.0
#127I'd say remove some of the old obscure never used words from the standard. And allow ANY custom operation for extensions and custom API (think java-script and programs).
Re: Let's remove verbs from HTTP 2.0
#128Earlier quoted context omitted.
And 99.9% of requests are GET rather than POST, so shall we get rid of POST then?
His point was that at minimum you still need a GET and POST for read and write. So comparing the numbers against bike-shed implementations is moot. Of course the number of reads will be significantly higher.
You could write and read using just POST. SOAP is the living example of that. So I think his point is inconsistent.
Re: Let's remove verbs from HTTP 2.0
#129Earlier quoted context omitted.
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
No, the verb is FOLLOW, as in the example you were responding to:
FOLLOW /user/123/followers/followers/followingRe: Let's remove verbs from HTTP 2.0
#130Earlier 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.
That's Twitters'.
Twitter has no concept of edit for a tweet. Is it surprising then that they don't need to use PUT or PATCH?