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

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 30 Nov 2007 11:25:10 -0500

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.


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.