Marc,
> > public class Entry {
> > @MediaType
> > public String getType() {...}
> >
> > @RedirectRef
> > public URI getContentLocation() {...}
> > }
> >
> > Otherwise:
> >
> > @Method
> > public @Metadata(mediaType="text/foo", language="en") Entry
> > postEntry(@Input InputStream data, @MediaType String type) {
> >
> > or
> >
> > @Method
> > public @MediaType("text/foo") @Language("en") Entry
> > postEntry(@Input InputStream data, @MediaType String type) {
> >
> 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.
> I like the idea of being able to specify additional metadata like
> language declaratively but you do run into a problem with annotation
> syntax: as soon as you have more than one field in an annotation you
> are forced to include the field names even when only specifying the
> value of one field where all the others have defaults. E.g. with one
> field you can write:
>
> @MediaType("text/foo")
>
> with two you can write:
>
> @MediaType(mediaType="text/foo", language="en")
> or
> @MediaType(mediaType="text/foo")
>
> but you can no longer write @MediaType("text/foo").
>
> You can always add more single field annotations but then you get an
> explosion of annotation classes.
In my the version of the API I described, I identified only 15 annotations:
- Representation, Input, Output
- Resource, Param|Context, Method, Status, Metadata
- MediaType, Language, CharacterSet, Encoding, Expires, LastModified, Tag
We may need a couple of enumeration, too. That seems far from an explosion
;)
Best regards,
Jerome