On Jun 22, 2010, at 9:01 AM, Jason Winnebeck wrote:
> 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?
>
It's a fair point but IMHO if you are using a media type of text/plain
it is much clearer if you do:
return new Integer(1).toString();
as then you know exactly what the on the wire format is. Also your
client is essentially binding with out of band knowledge that the text/
plain representation returned is processable as a number value. But
that might be OK for your requirements.
> 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 do not necessarily think that a Java object graph has a one to one
correspondence to some form of hypermedia-based serialization. You
need to decide what data is important, assign URIs to that data so it
is accessible, assign media types for representations of that data so
the client can consume it, and those media types will specify what the
client can do with links in the representation, in addition to
specifying link types that can also define what the client can do with
links.
JAX-RS provides a way to make it easier to build URIs, but it
currently does not provide an easier use mechanism for hypermedia.
Jersey is experimenting with potential ways to make this easier on the
client and server.
Also not all representations need to have links, returning something
simple can make sense depending on what you are doing (e.g. a hit
counter, or just some time value perhaps e.g. last rebooted)
> 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?
>
Even just a property format, it does not have to be XML or JSON. Or
even a media type that better describes that the representation is a
number. I suppose one could invent:
text/number
:-) i actually do not know if such a media type exists. But if you use
such a media type then returning an Integer would make much more sense
to me.
Paul.
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>