Re: Representation<T> and Entity<T>

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 10 Apr 2007 12:27:51 +0200

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.


| ? + ? = To question
    Paul Sandoz