Live data from Hacker News

Let's remove verbs from HTTP 2.0

onebigfluke.com

81–90 of 141 posts

Re: Let's remove verbs from HTTP 2.0

#82
post #64
post #59

Earlier quoted context omitted.

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

not necessarily mapped to database records Examples? nor even behaving like so. Examples?

Your API could be mapped to a filesystem. (Although you might consider consider a filesystem a database.) If this were the case, it would make sense to use PUT for commands like chown and chmod, which are idempotent. Calling "PUT" "CREATE" here would (IMO) be confusing. I'm not creating something. I'm performing an action, putting things in their proper place, if you will. Another example could be home automation. You might design a REST API where you can PUT cameras to turn them on.

The way I see it, the great thing about HTTP verbs is that they are mostly (not all) unbiased about what they map to, and allow us to be more descriptive. If I'm inspecting the requests my browser is making, I'd much rather see "DELETE /path/to/resource" than see "POST /path/to/resource" and only discover that that call deleted my resource because the body of the request contained '{ "action" : "delete" }'.

Re: Let's remove verbs from HTTP 2.0

#83
post #80

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

Hyperbole means exaggerating something, usually for emphasis or humor. Even taking your comment as hyperbole, the intended, non-exaggerated meaning still appears to be "this person has insufficient experience to speak on this subject." But the person in question is actually very experienced in this area. Given that, I don't think we can blame James if he didn't understand — it's hard to see what the actual meaning behind the statement could have been.

Re: Let's remove verbs from HTTP 2.0

#84
post #64

Earlier quoted context omitted.

not necessarily mapped to database records Examples? nor even behaving like so. Examples?

Your API could be mapped to a filesystem. (Although you might consider consider a filesystem a database.) If this were the case, it would make sense to use PUT for commands like chown and chmod, which are idempotent. Calling "PUT" "CREATE" here would (IMO) be confusing. I'm not creating something. I'm performing an action, putting things in their proper place, if you will. Another example could be home automation. Yo…

Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE. The permissions and owner values already exist by value of the record existing, so of course trying to call CREATE on them seems silly. Same with turning cameras on/off; that's UPDATE on the state on the camera. CREATE would be to add a new camera to the system.

Re: Let's remove verbs from HTTP 2.0

#85

Earlier quoted context omitted.

Your API could be mapped to a filesystem. (Although you might consider consider a filesystem a database.) If this were the case, it would make sense to use PUT for commands like chown and chmod, which are idempotent. Calling "PUT" "CREATE" here would (IMO) be confusing. I'm not creating something. I'm performing an action, putting things in their proper place, if you will. Another example could be home automation. Yo…

Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE. The permissions and owner values already exist by value of the record existing, so of course trying to call CREATE on them seems silly. Same with turning cameras on/off; that's UPDATE on the state on the camera. CREATE would be to add a new camera to the system.

> Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE.

Right, which is why calling PUT to do them "CREATE" would be confusing. But PUT is still the right verb (well, for things like chmod 777; for chmod +X, PATCH would be better.)

PUT isn't "create" its "assign".

Re: Let's remove verbs from HTTP 2.0

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

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 few resources show all its properties in public, and if you're not replacing the resource, is PUT the right semantic?

Re: Let's remove verbs from HTTP 2.0

#87
post #22
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…

"Execution in the Kingdom of Nouns" is excellent. Anyone who hasn't read it should do so immediately. I want some expansion of verbs, counterbalanced with the elimination of some of the less useful verbs. The focus should be towards forcing webbrowsers away from GET and POST. OPTIONS should be made mandatory.

Thank you soo much for "Execution in the Kingdom of Nouns". It 's been a while since I cried laughing. As someone who's been programming in java since 97 (..God I'm old) I certainly saw myself wandering around the Kingdom of Nouns

Re: Let's remove verbs from HTTP 2.0

#88

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.

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 APIs. Have you read through the developer docs for most APIs?

(edit: typo)

Re: Let's remove verbs from HTTP 2.0

#89

Maybe I'm completely off, but in my opinion HTTP verbs are semantically on a lower level. I know that the classic OSI model only has seven layers, and HTTP is in layer seven, but for me, the actual web application using HTTP is in a layer above that. There are side effects to using those verbs that depend on browser and web server used. For example there may be cases where want to use POST instead of GET even for sim…

For example there may be cases where want to use POST instead of GET even for simple data retrieval, just because you're transmitting a credit card number or other sensitive information and you don't want it to be stored in the web server logs or the browser history.

If you're transmitting any information to the server to be processed/stored, sensitive or not, you shouldn't be using GET at all, per the spec.

GET params are nice for stuff like filtering and parameterizing the rendering of the representation, but surely a CC number is not adequate for such use cases.

Re: Let's remove verbs from HTTP 2.0

#90

Earlier quoted context omitted.

Hadn't read it. Did so immediately. Very good read! God I love it when people hate on java. (I know I shouldn't, but I do.)

He's not only bashing java but writes a lot of java. Are you as comfortable with that?

I write tons of Java in my day job, and at this point it only hurts when I laugh.
Post reply on HN