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.