On 2/7/06, rob yates <[EMAIL PROTECTED]> wrote: > > we'd love to see PaceCompoundEntries as an extension and ensure that > the base had enough in it to ensure that this type of extension was > not at odds with APP. > > as well as having a discussion on the technical merits of > PaceCompoundEntries we are also interested in seeing if anyone else is > having interop issues with the current treatment of media resources. > > I'd like to walk through the example in the specification (section > 12), which caused us a fair amount of confusion and use it to also > highlight some of our current problems. > > > 12. Atom Publishing Protocol Example > > > > This is an example of a client creating a new entry with an image. > > The client has an image to publish and an entry that includes an HTML > > "img" element that uses that image. In this scenario we consider a > > client that has IRIs of two collections, an entry collection and a > > media collection, both of which were discovered through an > > introspection document. The IRI of the entry collection is: > > > > http://example.net/blog/edit/ > > > > The IRI of the media collection is: > > > > http://example.net/binary/edit > > > > First the client creates a new image resource by POSTing the image to > > the IRI of the media collection. > > > > POST /binary/edit/ HTTP/1.1 > > Host: example.net > > User-Agent: Thingio/1.0 > > Content-Type: image/png > > Content-Length: nnnn > > Title: A picture of the beach > > > > ...binary data... > > > > The member resource is created and an HTTP status code of 201 is > > returned. > > > > 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 > > > > I have edited what is in the current draft and removed the content > body as this is optional and is not returned by our server's > implementation. So now what is the client to do to get the readonly > url.
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
