Marc,
> > Beside, my suggestion to rely on (iv) in this case, it is also
> > important to
> > note that it unlikely that you would want to expose POJOs as
> > RESTful Web
> > services if you don't even have control on the source case.
>
> There's a difference between the POJO that forms the resource
> and the
> class you use for representations. I think its entirely reasonable
> that the methods of a POJO will work with things like String and
> InputStream and you can't directly annotate either of those.
Is there some standard way to express annotations using an external file
(like JAXB config files)? Maybe that is something worth suggesting to the
Annotation JSR EG.
Anyway, it is seems reasonable to rely on an annotated wrapper resource in
this case.
> > Note that I consider the usage of JAXB to serialize
> representations
> > as an
> > important use case. But if you autogenerate your POJOs from an XSD
> > schema,
> > then it is unlikely that your POJOs will expose media types other
> > than XML
> > ones, otherwise you would need to have control on them to generate
> > them
> > (JSON for example).
>
> That is true but there are many application/*+xml media types and
> other attributes like language to consider.
Agreed.
> > BTW, JAXB can also work using POJOs as an input instead
> > of an XSD schema.
> >
> Thanks, I'm aware of that, I explicitly said "when the Java class is
> auto generated" - i.e. my comment related to the starting with a
> schema use case.
OK.
> > @ParentRef("someuri")
> > @Input("application/bar")
> > @Output(mediaType="application/foo", characterSet="UTF-8")
> > public class SomeBean {
> > @Method
> > Foo postData(Bar bar) {
> > ...
> > }
> > }
> >
> It looks like we are very close to @ConsumeMime and
> @ProduceMime with
> different names. BTW, I'm fine with a name change and also switching
> the @ConsumeMime successor to be a class and parameter annotation
> rather than a class and method annotation.
Cool.
> > I agree that this is an important case to consider. There are
> > annotation based solution like:
> >
> > @Method
> > public Entry postEntry(@Input InputStream data, @MediaType String
> > type) {
> >
> There's already a general purpose @HeaderParam("Content-Type") that
> could be used instead of a specific @MediaType annotation.
As explained before, if would prefer to not refer to raw HTTP headers by
directly adress the HTTP semantics/data model.
The advantage of a @MediaType annotation is that you don't have to know the
exact name of the "Content-Type" header and don't have to know how to
extract the CharacterSet from textual content types (you would use the
@CharacterSet annotation). We could also add an annotation parameter
specifying if the parameters should be injected too (false by default).
Best regards,
Jerome