Hi Adam,
At Wed, 18 Jul 2007 18:28:15 -0600,
Adam Taft <[EMAIL PROTECTED]> wrote:
I believe it is a principle of REST as applied to HTTP. Of course,
my last name is not Fielding, so what do I know.
Well, its called REST, not Fieldingism, so it’s open to
interpretation. :)
I'm not exactly following what you're saying about "AFTER each
request". Again, here's how I look at it, with two examples; your
PUT example and a caching example.
First, let's establish what a "request" is: url + pre-condition
headers + HTTP method + message body (some methods requiring a message
body (like POST, PUT) and others not (like GET or DELETE)).
Here's the caching example:
Step 1) A client requests a resource via GET. It has not previously
requested this resource, so it has no ability to include a
If-Modified-Since or If-None-Match precondition header.
--- Client -------------------
GET /some/url HTTP/1.1
Host: foo
--- Server -------------------
HTTP/1.1 200 OK
Etag: "abcdefg"
message body
A 200 OK is returned, along with a new Last-Modified and/or Etag
header. For simplicity, we'll just use the ETag, which the client
records along with the cached version of the resource.
Step 2) A client makes a request for the _same_ resource using the
_same_ url. However, this time the client uses a If-None-Match
precondition in the request. Thus, the "request" itself (as defined
above) is different.
--- Client -------------------
GET /some/url HTTP/1.1
Host: foo
If-None-Match: "abcdefg"
--- Server -------------------
HTTP/1.1 304 Not Modified
The server replies with a 304 Not Modified reply. The server can
return a different status code because the request is different. It
will always return this 304 Not Modified reply until the resource
changes (for that specific request). It will always return a 200 if
the precondition header is not included. The server is unable to
escape these rules.
The point is, notice that the Request has changed. It doesn't matter
how many times you throw the first request at the server, it will
always return 200. Likewise, the second request will always return
304, until the resource's state changes.
This exact same evaluation can be applied to your PUT example, except
of course the server replies with Precondition Failed (which according
to the spec is an appropriate response for a PUT method under the
circumstance you describe). It will always return 412 after the first
PUT for identical requests (because the first request modifies the
resource, and thus allows the server to return a different status code
for the same request).
That's the core of my argument: A status code should always be the
same for an identical request so long as the resource has not change.
If the server is coded to return a different status code for an
identical request when the resource state has not changed, then that
is wrong. The only liberty a server has to return a different status
code for the same request is when the resource has changed.
Ok, but you argued against a DELETE returning 404 with the argument
that the response to a request should depend only on the state of the
resource AFTER the request has been processed (ie, a non-existing
resource). Otherwise, there is not a problem with returning a 204 or a
404 because the resource CHANGES; in the first case it is deleted, in
the second case there is no change.
Put another way (I hope this makes sense), your argument was for:
<request method, server state before> =>
<response status, server state after>
<DELETE, existing resource> => <204, non-existing resource>
<DELETE, non-existing resource> => <204, non-existing resource>
and against:
<DELETE, existing resource> => <204, non-existing resource>
<DELETE, non-existing resource> => <404, non-existing resource>
Because you insisted that the server should only care what the server
state is AFTER the request (that is, a non-existing resource) and
should not care what the state was like BEFORE the request (existing
vs. non-existing). Now you are saying that we SHOULD take into account
what the state is like before the request; that is, ETag: "A" or ETag:
"B", even though the state AFTER the request is processed (ETag: "B")
is the SAME.
You're right. PUT should never return 201 Created. The reason? 201
Created should have a Location: header sent in reply. The client
doesn't need a Location: header, since it already knows the location
the resource.
The client doesn't care whether the resource was _newly_ created, or
just _updated_. What does the client care? This goes back to the
same argument about DELETE. So long as the state change for the
resource occurred, that's all the client cares about, not whether it's
newly created or not. What is newly created anyway? And, what does
the client care to know the difference?
The 201 Created status code is only useful when the resource's URL is
not known by the client. Therefore, 201 Created is only applicable to
the POST method, because POST doesn't know what the url is for the
resource in its message body.
A successful PUT can return 204 No Content for an immediately
successful state change, or 202 Accepted for one that will occur in
the future. There are no other 2xx response codes appropriate for a
PUT operation.
Sorry, all these paragraphs are just wrong. From 9.6 (PUT) of RFC
2616:
| If a new resource is created, the origin server MUST inform the user
| agent via the 201 (Created) response.
Again, this is not arguing HTTP spec, as the HTTP spec is quite a bit
more lenient than the rules I've suggested. And, the rules I've
suggested may not strictly be REST rules, as I believe Fielding was
describing REST as an architectural pattern that is applicable to
protocols other than just HTTP.
It is arguing the spec, because (a) you are advocating something that
violates the spec, and (b) you were previously laying down as settled
law (do not return a 404 from a DELETE) that is not in the spec & and
is not clearly defined in Fielding’s thesis and may or may not follow
from these principles.
True, REST is applicable to other protocols.
However, if you follow the HTTP spec and you apply the REST principles
to it, I believe what you end up with is this logical mapping of what
HTTP status codes can be returned for which HTTP methods. For 2xx
only, it goes:
GET => 200, 206
PUT => 204, 202
POST => 201, 202, 205
DELETE => 204
Look, you can’t argue against a MUST in an RFC. Either you come up
with HTTP-next generation, or you follow the spec.
HTML is an abomination to the HTTP spec. So, I'm not arguing what is
in current use, more what it ideally should be.
Huh?
No more replies from me. I feel I've hijacked the thread, and we're
obviously way off RESTlet discussion. ;)
True, I didn’t mean to start all that.
best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
