Speaking as someone who is trying to do evangelize this internally, I have to say I haven't dared to try to describe all of these complications to people.
The Link headers seem like a good approach. (In the hypothetical example below, would the Content-Type: be application/atom+xml? Or would, or could, it be image/png?) John Joe Gregorio wrote on 2/7/2006, 1:27 PM: >... > > 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 > -- John Panzer Sr. Technical Manager http://journals.aol.com/panzerjohn/abstractioneer
