Let's remove verbs from HTTP 2.0
81–90 of 141 posts
Re: Let's remove verbs from HTTP 2.0
#82Earlier 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?
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
#83Earlier 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".
Re: Let's remove verbs from HTTP 2.0
#84Earlier 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…
Re: Let's remove verbs from HTTP 2.0
#85Earlier 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.
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"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…
-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
#87Arguing 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.
Re: Let's remove verbs from HTTP 2.0
#88Earlier 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.
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
#89Maybe 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…
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
#90Earlier 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?