On May 26, 2008, at 10:27 AM, Kevin Duffey wrote:
> Thank you for your reply. Ok, the GET stuff makes total sense. Use
> request parameters like any other GET call. I believe a GET should
> return the same result, every time as long as nothing updates it,
> hence your comment about caching and such. Makes good sense.
>
> Very interesting design with regards to my a/b/c example. I'll have
> to dig into that a bit more for sure. I'll be picking up that book
> too, but does it focus on JSR 311, or REST in general... or both
> perhaps?
>
The latter, plus other frameworks like Restlet and Ruby on Rails.
> BTW, I thought I saw somewhere that application/xml was a mime
> type, but I thought it was text/xml? Is there a difference?
MIME media types are general things, they can be anything, some are
standardized like the two you present. They identify the
representation in a request or response, and are also used for a
client to say what it prefers (is acceptable for a server to return).
See the Accept and Content-Type headers of HTTP, that utilize media
types.
> I know you use application/json to specify json input/output for
> content-type and accept headers. Just wondering if one way is
> preferred over the other for the xml input/output.
>
application/xml for general XML. application/xhtml+xml for XHTML.
application/atom+xml for Atom documents. You can create your own if
you want to specifically identify a restricted set of XML documents.
For maximum interoperability it is recommend to stick to standardized
or commonly used media types.
Paul.
> Thanks again.
>
> ----- Original Message ----
> From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> To: users_at_jersey.dev.java.net
> Sent: Monday, May 26, 2008 1:08:31 AM
> Subject: Re: [Jersey] Hello all
>
>
> On May 26, 2008, at 3:31 AM, Kevin Duffey wrote:
>
>> Hello all,
>>
>> Just started using Jersey with Glassfish v2, Netbeans IDE. I'm
>> kind of a noob to the RESTful stuff. I like that GlassFish has the
>> JSR-311 (I think its jersey) implementation built in... er, at
>> least I think it does, maybe its the Netbeans IDE plugin wizard
>> that adds it to my WAR/EAR files? I see a REST build.xml that gets
>> added when I use the wizards.
>>
>
> That would be NBs doing that for you.
>
>
>> Got a couple questions, was hoping some of you more experienced
>> guys/gals could answer.
>>
>> 1) At least with Netbeans, the wizard is nice... not used to using
>> GUI wizards for things. I was able to build/deploy and actually
>> access the GeneircResource I created. What I am not too clear on
>> is, the IDE wizard creates a getXml() and putXml() methods. The
>> getXml() has annotattions for @GET and @ProduceMime("application/
>> xml"), the other one has @PUT and @ConsumeMime("application/
>> xml"). So, first part of this question is, with the @GET, which I
>> was able to test with a simple browser URL to it, it does not
>> accept any input. Generally speaking, I would expect the ability
>> to call a GET handler and pass in either request parameters (?
>> key=value&key2=value), OR pass in a body of XML that provides some
>> parameters.
>
> The path of the client request URI, for the GET request, provides
> the scope for the server to determine what the resource is and
> therefore the set of representations that may be returned by that
> resource. If you want to restrict the information returned in the
> representation by a GET request then one would use query parameters
> in the URI. It is a potentially a matter of design taste but IMHO
> if you remove the query parameters from a URI and it returns an
> error then it can reflect poor RESTful design, more RPC over HTTP
> design in the server implementation.
>
>
>> As I am new to REST, I am not entirely sure if this is out of the
>> norm or not. Perhaps I am supposed to use a PUT in the case I need
>> to pass something in that can be used to dictate the response I
>> get back?
>
> PUT updates the state of a resource. If you do a PUT to a resource
> with some representation, it succeeds, then do a GET you should get
> the same information back (assuming no other third party has
> updated the resource) that you put.
>
>
>> My understanding tho is put/post "change/create" things, where as
>> GET just returns a response, and has no side affects based on any
>> input.
>
> No *unintended* side-effects. i.e. there can be side-effects just
> not ones that break the GET semantics, e.g. so hit-counters,
> logging are fine, a financial transaction to buy say a book is not.
> The reason is GET can be called again and again and the client is
> in the knowledge that it is safe to do say. This gives the Web some
> robustness in terms of failure. It is what makes caching and search
> engines viable.
>
>
>> So is it possible to pass in something into a GET handler that can
>> be used to help formulate the response?
>
> Yes, as long as it is in the URI :-)
>
>
>> Or are GET calls purely to return some sort of static-like (maybe
>> from a DB table, no logic applied, just a query) response?
>
> The representation returned from a GET request can use what ever
> logic as long as the semantics of GET are adhered to.
>
>
>> If you CAN specify parameters, do you put both a @ProduceMime & a
>> @ConsumeMine for one method? Or are u limited to one or the other
>> annotation per method?
>>
>
> Only @ProduceMime makes sense for GET as it does not consume a
> representation.
>
>
>> 2) I notice, at least in code completion. only @GET and @PUT are
>> available. Maybe it's just the IDE, are @POST and @DELETE not
>> available?
>
> I am not sure what exactly you are doing, but they are also available.
>
>
>> I am using the latest (from about a week ago) IDE plugin for
>> JSR-311. Haven't tried compiling with them, but I was guessing
>> they would also be present.
>>
>> 3) So, in my API, I have to handle something like so:
>> /a - resource
>> /b - diff resource
>> /c - yet another resource
>>
>> so this would be 3 classes. However, we have two many to many
>> relationships, such that A can "belong" to one or more Bs, and a B
>> can belong to one or more As. So we might have a
>> GET /a/{a_name}/b to get me all the Bs that belong to the A, and
>> vice versa, GET /b/{b_name}/a to get a list of all the As.
>>
>
> This is possible (the database->RESTful service generator does this
> such such patterns in the DB tables).
>
> @Path("a")
> public class AList {
> @Path("{name}")
> public A getAResource() { ... }
> }
>
> public class A {
> @Path("b")
> public BList getBResource() { ... }
> }
>
> @Path("b")
> public class BList {
> @Path("{name}")
> public B getBResource() { ... }
> }
>
> public class B {
> @Path("a")
> public AList getBResource() { ... }
> }
>
> There are many ways to compose the Java classes that model the
> resources.
>
>
>> How would this be handled in either A or B class (resource)? I am
>> not quite clear how when the GET /a is called, how do I set up the
>> method to handle the /a alone, and the /a/{a-name}... two separate
>> methods that are auto-called for me? Or do I have to parse
>> something myself to figure out the a_name in the 2nd call? In the
>> event of a GET /a/{a_name}/b ... I assume the /a resource is being
>> called, is there some automagic thing that is done by the JSR-311
>> to get me the a_name as well as the b... or do I have to do some
>> parsing to get down into it? Just wondering the scope of what I
>> need to learn to get this API I have to do working. I have about a
>> week left to make some magic happen. lol
>>
>
> The above example shows one way. The examples distributed with
> Jersey might help you. If you have time I recommend reading the
> book RESTful Web services [1] as i think this will help you
> understand the REST style better.
>
>
>> I will probably have some more questions down the road. Just
>> looking to get started and understanding how to use JSR 311.
>>
>
> OK! just ask away. If you have more general REST questions
> independent of JSR-311 and Jersey then i recommend you send email
> to the Yahoo rest-discuss list [2] as there are many experts on
> that list.
>
> Paul.
>
> [1] http://www.oreilly.com/catalog/9780596529260/
> [2] http://tech.groups.yahoo.com/group/rest-discuss/
>
>
>