I'd like to add a few things here.<p>Jersey is an implementation of JAX-RS. It has 3 major pieces: jersey-core, jersey-client, jersey-server. (The name should be obvious what they are for).<p>If you're writing JAX-RS services, you can return a few different formats: XML, JSON, ATOM. All you need to do is to annotate the method with the following annotation:<p><pre><code> // will return XML or JSON depending on the request from the client.
@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
</code></pre>
This is a big win if you need to support both.<p><pre><code> - Object to XML conversion is done by JAXB.
- Object to JSON conversion is done by Jackson via JAXB.
</code></pre>
Jersey is part of JavaEE 6 standard (part of your Application Server if it supports it).<p>What's lacking from JavaEE 6 is an MVC framework which is targeted for JavaEE 7.<p>Another key feature is JAX-WS (the plain old SOAP WebService). The nice thing about JavaEE 6 is that the minimum differences in the programming style between JAX-RS and JAX-WS.<p>JAX-RS operates according to resources (e.g.: give me all students, give me student with id=1, delete student with id=1, etc). So some of the examples would be:<p><pre><code> // Rough pseudo-code, omitting a few JAX-RS annotation
public class StudentResource{
@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
public <List> all(){}
@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
public Student get(long id){}
}
</code></pre>
JAX-WS operates according to services (e.g.: initiateInvoiceWorkflow, performPayment, etc).<p><pre><code> public interface AccountingService{
@WebMethod(operationName="initiateInvoiceWorkflow" ...)
Invoice initiateInvoiceWorkFlow();
}
// have your implementation...
</code></pre>
So in theory, you can have something that's called StudentRepository where you can use that repository with both JAX-RS (REST) and JAX-WS (WebService) implementation easily (I've done this and it's quite straightforward) if your "Enterprise client" forces you to do so.<p>The important bit here is testing. You can easily test both JAX-RS and JAX-WS implementation in both unit-test or integration-test. You can easily do unit-test because you don't need to deploy them to the server: they're just normal Java classes. You can do integration test by deploying them to the server and generates the client implementation (in which I'll cover next).<p>The client-side implementation of JAX-RS is also similar to that of JAX-WS programming style.<p>In JAX-WS, you grab a WSDL, throw it to a generator tool that comes with JDK to generate the model (Invoice, Student, etc) and the proxy client-side to call the server-side. Very very straightforward, 5 minute job.<p>In JAX-RS, you'd use jersey-client to perform HTTP call as follow:<p><pre><code> // url => is a string that points to JAX-RS end-point e.g.: student/1
// header => json? xml? atom?
// type => (typeof Student) (well... it's Java).
Student student = Client.create().resource(url).accept(header).get(type);
</code></pre>
Keep in mind that in the client-side, your Student class must have roughly the same structure and must be annotated using JAXB XML annotation (the client-side also relies on JAXB -> Jackson -> Java object conversion for the case of JSON, or just JAXB -> JAva object for the case of XML).<p>So no hacking using XPath or something like that (I work in Ruby once in a while and when I read some of the 3rd-party libraries/gems that implement client-side API against popular service provider, most of the implementations do brute force using XPath querying node element and stuff).<p>PS: Excuse me for the poor formatting, where can I learn to format my comment?<p>UPDATE: fix the format.<p>Oh and one more thing: JAX-RS (Jersey) is just an implementation on top of Servlet. So all of your previous knowledge regarding to Servlet (Context, deployment, URL, Filter) will be definitely useful.