REST Resource Discovery
- I've seen it said on this list and elsewhere that
REST means that a URL is all one needs to know to
interact with a resource. This sounds appealing,
but I have not seen a document specifying the
conventions necessary to achieve this.
Questions that I think need to be answered:
1. How do you know what MIME-types one may POST or
PUT to a given resource?
My proposal is that servers return accept-POST and
accept-PUT headers in response to GET requests,
however these headers are not actually defined
in any standard so perhaps there is another
approach. An issue with this approach is that it
implies that it is incorrect to have a resource
to which one is permitted to POST but not GET.
2. Is it permitted to have a resource that exposes
POST but not GET?
3. What is the correct RESTful response to a POST
My feeling is that if one returns a 200 OK, one
should return the result of a GET to that
resource. Otherwise return 204, or 201 or 303
with the relevant URLs. Is that correct?
4. How does one achieve transactional semantics
Perhaps this is entirely application level.
Create a transaction URL and POST commit to it
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax
> What's the problem?Good question. :)
People have been considering mechanisms for binding
metadata to a resource. HTTP Extensions for Resource
Metadata (HERM)  looks to be a good solution. It
calls for the use of a pair of headers, Meta-Location
We've been considering some potential refinements. I
felt that the OPTIONS method would be the natural place
to return the Meta-Location in the general case, which
is similar to the use of the Allow header. It's unclear
though if this is stretching the semantics of OPTIONS
too far. I'd like to know if it is.
Roy Fielding had mentioned in a posting to
this list that adding an extra header to each GET is not
optimal , but that might be the easiest road to
Other interesting ideas have been floated on the HERM
associated discussion list .
This topic is essentially one aspect of the TAG issue
"metadataInURI-31"  specifically with regards to
"... and more importantly there should be a "clean",
uniform way to refer to (and thus access) the metadata
of web resources..."
Another potential issue brought up by Berners-Lee in
a recent posting  to www-tag concerns a similar issue: how
can site level "metadata" such as /favicons, p3p statements
etc., be bound to a site in a standard way. It would seem
that the solution to the first issue could form the basis
of the solution to the second issue.