RE: JSR311: The best practice to return primitive types from a RESTful service?

From: Liu, Jervis <>
Date: Mon, 3 Dec 2007 02:37:18 -0500

Comment in-line.

> -----Original Message-----
> From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Sent: 2007121 0:25
> To:
> Subject: Re: JSR311: The best practice to return primitive types from a
> RESTful service?
> On Nov 29, 2007, at 10:49 PM, Liu, Jervis wrote:
> > Thanks for the reply. I do agree that returning an int is indeed a
> > fine grained style from the old RPC world, and this should be avoid
> > if possible. However, as Stefan mentioned, whether or not an
> > employee's age can be made a resource is really arguable, it is a
> > design choice made by users unless the JSR-311 API formally
> > prohibits doing so. So here is my question. As one of the goals of
> > JSR-311 is to prompt a resource-oriented programming model [1],
> > should not the JSR-311 spec provide a guide on how to deal with
> > returning primitive types either through API or at least a best
> > practice recommendation? At the moment, I see this is a hole not
> > addressed by the spec. I can imagine once JRS-311 is getting used to
> > build real applications, people will come out with the same question
> > again and again, "oh, I have a java method "int
> > getEmployeeAge(String employeeName)", how can I turn this into a
> > restful service using JSR-311?".
> >
> > Several options I have in my mind:
> >
> > a). in JSR-311 section 3.1.2, "An implementation MUST include pre-
> > packaged EntityProvider implementations for the following Java and
> > media type combinations:", add the support for Java Primitive types:
> >
> > Java primitive types All text media types (text/*).
> >
> > But with an statement that returning a fine grained primitive type
> > is not a recommended practice.
> >
> > Essentially this means a JSR-311 runtime implementation needs to
> > provide a PrimitiveEntityProvider to read and write primitive types
> > to/from entity body using text/plain content type, same as what we
> > do with String.
> >
> > b). Do not provide any support for Java Primitive types but
> > explicitly stated in JSR-311 section 3.1.2 that no default support
> > for returning Java Primitive types is because this is not a
> > recommended practice. But if users really want to do this, they
> > really understand the design choice they have made, they can do this
> > by registering their own PrimitiveEntityProvider on the JSR-311
> > container.
> >
> c) Use one of the primitive type wrapper classes (e.g.
> java.lang.Integer) along with a corresponding MessageBodyWriter.
> Thinking about it we could remove the need for a MessageBodyWriter by
> requiring the runtime to use the toString method when there's no
> MessageBodyWriter. The problem with that is that Object provides a
> default toString so it would be easy for an application to exhibit
> unexpected behavior if the MessageBodyWriter they provide isn't picked
> up for some reason. Essentially a class of error (missing
> MessageBodyWriter) would be hard to detect.

Hi Marc, did you suggest that the JSR-311 runtime provides a behavior such that when there is no MessageBodyWriter selected for the return type, Object.toString will be used to form an output( does this also suggest that in the case of no MessageBodyWriter selected, the default output content type is text/plain?). Or instead what you meant is defining a pre-packaged MessageBodyWriter in JSR-311 spec to handle primitive types. For the later, I dont see the difference between this and approach a). Using primitive type wrapper classes is the implementation detail of PrimitiveTypeMessageBodyWriter.


> Marc.
> ---
> Marc Hadley <marc.hadley at>
> CTO Office, Sun Microsystems.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland