Earlier quoted context omitted.
DELETE /sessions/:id
Except that that is almost never the way you would go about logging someone out. Which is precisely the point.
[deleted]
Let's remove verbs from HTTP 2.0
21–30 of 141 posts
Re: Let's remove verbs from HTTP 2.0
#22Arguing 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
#23Earlier quoted context omitted.
...and was a HTML element. Let's not throw out the baby with the bathwater.
It never was. has never, ever, ever been part of the HTML spec or even the HTML drafts. At best, it was an easter egg.
And SPACEJUMP has never been part of the HTTP spec.
Nor (unlike in HTML) has it been part of HTTP implementations, AFAICT, at least, as an HTTP verb.
The "SPACEJUMP" and "TEXTSEARCH" methods appear to be patterns for use of the GET verb.
Re: Let's remove verbs from HTTP 2.0
#24Good read, plus I'd never read the email that introduced the bike-shedding metaphor: http://white.bikeshed.com
Re: Let's remove verbs from HTTP 2.0
#25Re: Let's remove verbs from HTTP 2.0
#26If anything, I'd rather have a HTML spec that allows forms to do the other resource oriented verbs.
Yes! Why is support for PUT and DELETE not specified in HTML specs? Also, why hasn't a browser implementation gone ahead and added support for both of those verbs as an extension beyond the spec?
Re: Let's remove verbs from HTTP 2.0
#27There 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…
> At the moment the only way for an intermediary to know whether a request is finished is because it understands these methods, and this is also true of any extension methods
I read the HTTP 1.1 RFC differently. Requests must indicate a body with a Content-Length or Transfer-Encoding header. Responses always have a body (sometimes of length 0), unless it is a response to a HEAD request or has one of a very small number of response codes. http://tools.ietf.org/html/rfc2616#section-4.3
Re: Let's remove verbs from HTTP 2.0
#28Removing DELETE and PUT would be a terrible idea, every REST API would break.
I thought someone would say this and I'm afraid it's bullshit. You can just put the REST operations in the URL. This also has the advantage that you aren't artificially restricting yourself to CRUD operations. Some operations do not map to those, e.g. logging out (DELETE user? ... No... DELETE session? I guess?). I explained in more detail here: http://stackoverflow.com/questions/2191049/what-is-the-advan...
> 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
URI: specifies a combination of the resource against
which an action is to be performed, and some
information about the action that is to be performed
against the resource
Method: specifies incomplete information about the
action to be performed.
> This also has the advantage that you aren't artificially restricting yourself to CRUD operations.
I'm try to think of an operation in a system that can't be fairly clearly represented with the semantics of HTTP/1.1 verbs + PATCH, and failing.
> Some operations do not map to those, e.g. logging out (DELETE user? ... No... DELETE session? I guess?).
DELETE session is pretty natural. PATCH session to change the status to closed or, if the session status is its own resource, PUT closed to the status, are also options.
Re: Let's remove verbs from HTTP 2.0
#29Earlier quoted context omitted.
DELETE /sessions/:id
Except that that is almost never the way you would go about logging someone out. Which is precisely the point.
> Except that that is almost never the way you would go about logging someone out.
Its the way I would go about logging somebody out. Why wouldn't you?
Re: Let's remove verbs from HTTP 2.0
#30I can't agree with the assertion that the methods defined in HTTP since 1.0 are bike-shedding. I'll agree that lots of the the HTTP methods defined in standards other than HTTP are unnecessary cruft (particularly in light of the REST model) -- WebDAV and friends particularly -- but I don't see why you'd want to eliminate any of the HTTP/1.1 verbs (or PATCH) in HTTP/2.0, except maybe replacing HEAD with a no-content m…
CONNECT is used to get a raw socket connection through a HTTP proxy. There'd be no way to get SSL/TLS to work with a proxy without it (save using SOCKS instead of HTTP to talk to the proxy).