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.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.