On Apr 10, 2007, at 8:36 PM, Marc Hadley wrote:
> On Apr 10, 2007, at 2:10 PM, Jerome Louvel wrote:
>>
>>>>> None of those helps when the return type can't be modified and the
>>>>> media type isn't know in advance.
>>
>>>> In this rather unlikely case, it could simply rely on a wrapper
>>>> POJO that
>>>> would get annotated and would know how to "dynamically
>>>> serialize" the wrapped POJO.
>>
>>> Its not an unlikely case, see APP, WebDAV, Amazon S3 etc.
>>
>> True, but the implementation of those use cases based on
>> *unmodifiable*
>> classes does seem unlikely.
>>
> I disagree, I could see Representation<File> or
> Representation<InputStream> being used in those cases.
>
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.
>
>> @RedirectRef is strictly equivalent to "ContentLocation" and
>> @Location.
>>
> But the two are different, Location is used outside of redirects,
> e.g. with a 201 response. IMO it would be confusing to use some
> kind of Redirect annotation where you aren't actually redirecting.
>
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