[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] REST vs. HTTP in the real world



On Tue, 29 May 2007, Nicholas FitzRoy-Dale wrote:
> John Elliot wrote:
> > If anyone would like to defend PUT and DELETE I would like to hear
> > their case. What value do PUT and DELETE provide, and why should I
> > accept them as useful or necessary?
>
> Wasn't PUT supposedly to be the complement of GET? IE you GET a bit
> of structured data (JSON or whatever) and then make changes to it and
> PUT the same data back. This is very neat if you're one of those "Web
> file system" types

The concept of a 'resource' and the concept of a 'file' are far from the 
same thing, even if they do correlate well in some problem domains.

Think about what this means in consideration of concurrent users, 
versions, and middleware:

"Methods can also have the property of "idempotence" in that (aside from 
error or expiration issues) the side-effects of N > 0 identical 
requests is the same as for a single request. The methods GET, HEAD, 
PUT and DELETE share this property."

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2

That goes even more so for when a Resource doesn't correlate well with a 
File.

Btw, the spec goes on to directly contradict itself:

"If the Request-URI does not point to an existing resource, and that URI 
is capable of being defined as a new resource by the requesting user 
agent, the origin server can create the resource with that URI. If a 
new resource is created, the origin server MUST inform the user agent 
via the 201 (Created) response. If an existing resource is modified, 
either the 200 (OK) or 204 (No Content) response codes SHOULD be sent 
to indicate successful completion of the request."

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

So, if I were to PUT a presently non-existant resource and then PUT the 
same resource again, per 9.6 I'd have different effects in each case 
(in the first case a "creation" effect, in the second case "no effect". 
Note that "creation" itself might have its own additional side-effects, 
or be necessarily contingent on previous operations.), and get 
different responses in each case. (That's even without considering 
concurrency, or the effect of changing permissions between requests, 
etc.)

Effect bearing operations can not really be idempotent.

> but even makes sense in a more limited domain (eg 
> the policy editor for the bug tracker I'm writing runs in the
> browser, requests policies from the server in JSON format and then
> posts back the same data (modulo any policy changes the administrator
> just made). It seems like a good use for PUT, but I didn't actually
> choose PUT because I haven't been bothered to find out how well it's
> supported.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

"HTTP/1.1 does not define how a PUT method affects the state of an 
origin server."

"The fundamental difference between the POST and PUT requests is 
reflected in the different meaning of the Request-URI."

My observation is that those "differences in meaning" are highly 
subjective, application defined, and not worth isolating distinctly in 
a universal context.

Further, introduction of complexity should come with some benefit. 
Where's the benefit?

> The alternative (POST) isn't supposed to be symmetrical and is
> basically about submitting form data (only).

I'm not sure what you mean by 'symmetrical' (I can guess), but in any 
case the effects of PUT, POST, or DELETE are undefined:

 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

I'd say that POST is a semantic-free non-idempotent verb, and that 
thinking in terms of GET and POST is the best way to go.

> PUT seems pretty simple, so I don't really see how it can be
> standardised wrongly. But I have been very wrong in the past about
> Web standards I'm not going to pretend I know much about it.
>
> I don't really understand DELETE because the obvious argument in its
> favour implies a corresponding CREATE to me. Perhaps there is one.
>
> Also why was 80% of your post in the future tense?

...because I'm prepared to go to to mind numbing detail to justify my 
assertions. :)

Nathan wants to argue the point with me, so I figured I'd kick things 
off.

I don't see why this conversation need be me vs. Nathan, though. So I 
invited other contributions.






-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.