Jerome Louvel wrote:
>> The above is similar to approach (ii) above except the ConsumeMime
>> annotation has been removed so the method will be called for any
>> media type. Here the media method parameter contains an input stream
>> from which to read the entity body and additional metadata including
>> the media type and language. Without the Entity class the developer
>> would either have to create a new class to do the same job
>> along with
>> a serializer and deserializer for that class or use a low level API
>> to extract the Content-Type (and possibly other) header from the
>> request. The same problems occur when a method needs to return
>> something where the metadata isn't known in advance. I think these
>> are common enough use cases that its worthwhile standardizing the
>> Entity interface and Representation class to save developers the
>> additional effort their omission would cause.
>
> 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) {
>
How would one return the media type, language, or content location?
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.
> 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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109