Jerome Louvel wrote:
> 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) {
>
IMHO this puts more work on the developer. They have to create their own
code for some very common cases.
>> 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.
>
I agree. This is possible with the existing API proposal.
> 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.
>
Yes, if only we could :-) In the shorter time-frame we may be able to
get some sharing between Servlet and this API, which could in time get
put into the JDK. I think it is worth pursuing.
>>> 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.
>
Yes, I like the idea of including language and character set (i do have
a preference for avoiding field names in annotations for the common cases).
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109