Well I am still learning the REST paradigm. I was building a small example for
myself just to play, and coming without a lot of web experience (but being
turned off by the complexity I saw in things like SOAP, which is anything but
simple), I was thinking, if I have a site with /counters/abc/count for
example, which outputs the counter's value, why do I need anything more
complex than to simply return the count as a number?
I can see in other "view" representations like a JSP maybe you want commas,
scientific notation, etc. I'm liking the fact the JAX-RS resource classes are
more like POJO models that just happen to have a web interface. In this sense
you just need to return a number that something can parse, and
Java/C++/C#/Python/etc client can all parse the various number formats
agnostically just fine, but not all clients would have the benefit of JAXB, so
why wrap into XML?
If I was making an HTML page for human viewing, wouldn't I use JSP or
something else to format the number however I wanted it then?
For the higher-level URLs, like /counters, I would need XML in that case. I
suppose you could argue that is not consistent, and a client of my service
would need to handle XML anyway.
What I haven't figured out yet is if I should be including tons of URIs in my
objects that I return? If I do that then I form a "web of hyperlinks," but
then my objects become less like normal Java POJOs and would lead clients to
have to create their own model. Is there a way to automatically convert
references to and from URIs? A Teacher might have a List<Student> in Java
world but in a web world maybe it would be a list of URIs to /students/{name}
which represent the students.
I'm assuming by "self-describing" you're speaking more like the hyperlinked
model I just described along with tagged formats like XML or JSON?
Jason
On 6/22/2010 11:43 AM, Paul Sandoz wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>