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

Re: Open Questions on using the Atom Feed Format for search results


On Sep 28, 2005, at 7:03 PM, Robert Sayre wrote: 
I certainly didn't get it either. In particular, I find it pretty
subtle that a resource that would give a 404 if you were to issue a
GET would respond with 412 here, because the server must check for an
entity before it checks for the existence of a resource.


A resource in HTTP is the mapping from URI to representations
over time.  When the server checks for a representation (what
becomes an entity when it is stuck in an HTTP message), the
server is being the resource.  A resource is assumed to exist
unless the server responds with 410, since the mapping is
discontinuous.

404 means it did not find a representation.  GET -> 404 and
PUT -> 200 is exactly what I would expect, since PUT is the way
to create representations and thus would never result in 404
(401 and 403 are far more likely).

If-match simply modifies that expectation to be conditional
on the presence of a representation, since there are some
applications of HTTP that want to be sure that no one else
is messing with the resource during the process of editing
an existing representation.  Thus, a result of 412 tells the
client that their expectation turned out to be wrong.

At some point during the process of specifying HTTP we tried
to translate the spec into a table of methods and expected
response codes.  I'm not sure what happened to that, but the
result wasn't any easier to read (due to the text-only
limitation on RFCs).  APP could include such a table without
re-specifying the meaning of each response code.

It will be
completely arcane to a client implementor whose last 5 projects have
been SOAP things.

I recommend erasing such memories before trying HTTP.

That doesn't mean we need to explain this in the spec, but I think
collecting stuff like this will be good for an implementation guide.
I've even started one:

http://www.intertwingly.net/wiki/pie/ProtocolFaq

Yes, good idea.

....Roy