Henry Story wrote:
> On 9 Mar 2006, at 18:28, James M Snell wrote:
>> That's an option, but I shouldn't have to parse Atom just to get a URL
>> when an HTTP response header would work.
>
> I suppose its a choice between having to invent a header for each of the
> metadata elements that can appear in an entry (which could be a lot
> given all the use cases that are bound to come up), or just returning an
> entry.
>
No need to invent anything. The minimum requirement here is to
communicate a couple of URL's, that can be done using the already
existing Link header. If you need more expressive metadata, you have
the option of including the Atom entry if you'd like... but doing so
should not be a normative requirement.
> For example as Aleksander Slominsky just recently pointed out, he would
> like to edit the metadata of media collections. In order to do this the
> header would also have to include a link to the edit location of the
> entry. And perhaps we should also return the id of the entry in the
> header too, just so that the server know the relation between this id
> and the media resource just posted, without having to search through
> collections.
>
Look at PaceFixMediaCollections again,
Location: http://...
Link: <http://...>; rel="edit",
<http://...>; rel="alternate"
The edit link rel points to the editable metadata representation.
The alternate link rel points to the alternate referenceable representation.
This link header would be included in the POST response AND in the
response to a GET/HEAD on the Location URI, giving you a consistent and
persistent link between the various resource representations and URLs.
- James
