Hi Jason, Craig,
In JAX-RS and in Jersey we decided not to directly support primitive
types for entities because there is no one singular format that might
be ideal in all cases (should leading zeros be present, should
scientific notation be used?). I suppose one could default to the Java
toString and valueOf semantics.
Note that in the case of URIs it is the server that defines the
structure and the client is not required to know what that structure
is, unless it is informed by the server.
We also tended to avoid the support of such primitives because it
results in a representations that are not very self-describing, unless
you use a particular media type rather than text/plain.
In some cases it might be better to return a triple of a name, the
type and value.
But i can understand for pragmatic reasons why this might be useful.
If we consider support for this in Jersey it would be something i
would prefer that would not be enabled by default and the developer
would need to explicitly register for such support.
Paul.
On Jun 21, 2010, at 10:05 PM, Jason Winnebeck wrote:
> Hello all,
>
> I am learning Jersey 1.3 and so far have been amazed at the
> "automagicality" provided by JAX-RS -- how little you have to do to
> set up a powerful REST interface.
>
> What I was surprised to learn is that I could not return and take
> primitive types as entities in the resource methods like it can as
> @PathParam:
>
> @GET @Path( "{name}" ) @Produces( "text/plain" )
> public long getCounter( @PathParam( "name" ) String name )
>
> @POST @Path( "{name}" ) @Consumes( "text/plain" )
> public long addCounter(
> @PathParam( "name" ) String name,
> long toAdd )
>
> It's quite possible I missed something, but also possibly not
> because normally people are working with more complicated (JAXB)
> POJOs so this is not a typical case.
>
> I drafted a NumberProvider which can handle the numeric primitive
> types (not char and boolean). Assuming I am not missing something,
> maybe this is something useful for Jersey to support out-of-the-box?
> The code could probably be also made more generic for many more
> types, but I restricted it because I wasn't sure if it's best to try
> to work automatically with complex user types, where String might
> work technically but not be appropriate in the external interface.
>
> It converts the primitives to and from String, and if a nullable
> type, converts "null" to null. It does the same for outgoing, but it
> appears that Jersey treats a null return as 204 code rather than
> going through the provider (seems reasonable, rarely would you want
> to return null).
>
> I tried to do some error handling by returning 400 (I think that's
> right?) if the number can't be parsed.
>
> Jason
> <
> NumberProvider
> .java
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net