Paul,
> We have implemented Atom-type services and S3-type services
> using the
> API proposal without requiring modification or wrapping of
> the chosen
> types. The ROME library was used for the former and InputStream was
> used for the latter. As the developer of such cases if i had to
> modify or wrap the types i would not be very happy. It would make me
> do more work and get in my way of getting the job done.
Ok, I think I've agreed 10 times now :) to the need of a wrapper
Representation<T> as long as it is not the default or recommended way to
expose representations. For other cases, it is definitely useful.
> In APP both Location and Content-Location can be set [1]:
>
> "If the creation request contained an Atom Entry Document, and the
> subsequent response from the server contains a Content-Location
> header that matches the Location header
> character-for-character, then
> the client is authorized to interpret the response entity as being
> the representation of the newly created Entry. Without a matching
> Content-Location header the client MUST NOT assume the returned
> entity is a complete representation of the created resource."
>
> FWIW Content-Location can be an absolute or relative URL whereas
> Location can only be an absolute URL.
>
> Paul.
>
> [1] http://bitworking.org/projects/atom/draft-ietf-atompub-
> protocol-14.html#crwp
I was only talking about the HTTP "Location" header but got confused with
the "Content-Location" one which is different but also useful I agree. This
actually reinforces my point that "RedirectRef" is a better than name than
"Location". We can however keep the "Location" property on the
Representation<T> class which is equivalent to the concept of "Content" (and
Entity) in HTTP.
Best regards,
Jerome