Paul,
> > @Method
> > public Entry postEntry(@Input InputStream data, @MediaType
> String type) {
> >
>
> How would one return the media type, language, or content location?
If the Entity class can be modified:
public class Entity {
@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) {
> In the above example I do see how the @MediaType makes it easier for
> developers or that it adds any value to the API. A Java class will do
> just fine, for example:
>
> public Entry postEntry(@Input InputStream data, MediaType type)
>
> And MediaType can provide support for getting access to parameters on
> the media type.
I do see the value in the MediaType class. There is a very similar one in
the Restlet API. But I don't think this class should be mandatory for POJOs
annotated with the JSR API. I would go even further: no class specific to
JSR 311 should be mandatory for a proper usage of the annotations. So, it
should be possible to get the media type as a String.
As for the MediaType class, I would prefer to see it directly added to the
JDK (in java.net) rather than in this JSR so that other APIs and JDK classes
could benefit from it, like the URLConnection class.
> > Note that @Input is a specialized version of
> @Representation pointing to the
> > representation received as request entity.
> >
>
> It seems like we are converging on a solution as Input/Output is very
> similar to Consume/Produce.
Indeed :) The advantage of @Input/_at_Output is that they can specify more
constraints (language, character set, etc.) than the
@ProduceMime/_at_ConsumeMime annotations.
Best regards,
Jerome