I generally concur with Heiko's points, an int looks rather fine
grained. However what you want to do could be achieved by writing a
MessageBodyWriter<Integer>, changing the method signature to return
Integer and taking advantage of autoboxing to do the conversion from
int to Integer for you.
Also, just to be clear, in the spec "text/*" is meant in the wildcard
sense. You should actually use something like "text/plain" for plain
text.
Marc.
On Nov 29, 2007, at 4:18 AM, Liu, Jervis wrote:
> It is mentioned in JSR-311 section 3.1.2 that "An implementation MUST
> include pre-packaged EntityProvider implementations for the following
> Java and media type combinations: java.lang.String All text media
> types
> (text/*).". However I don't see any places in the spec mentions about
> the conversion between a Java primitive types and an entity body. It
> is
> a common use case that I want to map my SQL "select employee _age from
> employee where employee _name='john'" to a java method "int
> getEmployeeAge(String employeeName)" then expose this as a RESTful
> service. Is this the correct way to do REST, or I am still having my
> head in a Service-oriented world instead of resource-oriented? Anyway,
> let's say my use case is indeed valid, in this case what content
> type I
> shall use to return an int type so that the client can make sense of?
>
> Shall I return int using content type "text/*"? In the case of
> returning
> String, as long as the client knows the returned content type is text,
> it should always be able to marshal the response body to a String
> without making any further assumptions. However this does not work for
> int type. If only information I have on the client side is the content
> type "text/*", it would be impossible for me to make sense of the
> response, is it a int type, is it a double type? I simply do not know.
>
> Or maybe, return an int using "text/*" is not a good practice in the
> RESTful world, using "application/xml" would be better. Can I say
> exposing a java method whose signature is " int getEmployeeAge(String
> employeeName)" is not a good practice, you should always wrap the
> result
> in a Java object instead, e.g., like " Employee getEmployeeAge(String
> employeeName)"? Or maybe, the JSR-311 runtime can go a little bit
> fancy,
> for example, it can generate a wrapper automatically on top of java
> primitive types so that the returned result is a valid an xml doc.
>
> Any thoughts would be highly appreciated. And should not JSR-311 spec
> include a section to describe how to do the conversion between a Java
> primitive types and an entity body?
>
> Thanks,
> Jervis Liu
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.