These solutions would be fine for us if
a) it was in the spec
or
b) other implementors agreed to do it the same way
It shouldn't come as any surprise to anyone, but I'm particularly
partial to the Link header approach.
- James
Joe Gregorio wrote:
Well, one option is to make returning the content body
a MUST level requirement. That would ensure the client
gets the info it needs. The other is to add some Link: headers
ala PaceUseLinkHeaders or PaceUseLinkHeaders2.
HTTP/1.1 201 Created
Date: Fri, 25 Mar 2005 17:17:11 GMT
Content-Length: nnnn
Content-Type: application/atom+xml
Location: http://example.net/binary/edit/b/129.png
Link: <http://example.org/imagemetadata/129.atom>; rel="edit"
Link: <http://example.net/binary/images/129.png>; rel="external"
Don't get caught up on the exact value of
the rel values, the *idea* is that the links you
need are returned via Link: headers in the response.
Note also that there are two links, one points to the
URI of the resource to be used for public consumption "external",
and "edit" points to an Atom Entry created in a collection
that handles metadata for media entries.
-joe
--
Joe Gregorio http://bitworking.org
