Hi Jerome,
I apologize for beating that one to death, but I still have questions...
> It seems that the Atom Publishing Protocol spec slightly diverges from HTTP
> 1.1 spec on this case.
I'm sorry, I quoted an early draft. The current APP draft states:
When the server generates a response with a status code of 201
("Created"), it SHOULD also return a response body, which if
provided, MUST be an Atom Entry Document representing the newly-
created resource.
They went from 'MUST also return a response body' to SHOULD. So, it's now less
of a divergence.
This point being clarified, I'd be interested in seeing how you'd implement
the following scenario:
- A collection contains images and videos
- When the client creates an image (by POSTing to the collection),
it expects to get back a thumb nail of
that image (if created successfully) in png format (the server is
responsible for creating the thumbnail).
[I know, it's a dumb example, for it's just for discussion's sake]
Here is what the client would send to create an image:
POST /collection
Name: mycat.jpg
Accept: image/png
< binary content>
What do CollectionResource's constructor and CollectionResource.post look
like?
The constructor defines the variants for a collection resource
(getVariants.add(...)). Obviously, image/png isn't one of them. Therefore,
CollectionResource.getPreferredVariant returns null.
Now, CollectionResource.post must create an ImageResource,
and return a representation of this resource by calling
ImageResource.getRepresentation(Variant variant).
Does does CollectionResource.post know that the preferred variant is
image/png?
My guess:
post(...) {
[..]
ImageResource image = new ImageResource(...);
// find the factory and client info
[...]
Variant v = factory.getPreferredVariant(clientInfo,
image.getVariant);
return image.getRepresentation(v);
}
It is my understanding that you'd have to follow this pattern every time you
create a resource by POSTing to a collection.
-Vincent.
