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/