By Jim White (Intertech Instructor and Director of Training)

Last Thursday (April 15th), I presented in our virtual classroom on RESTful Web Services in Java, an introduction to the new JAX-RS API.  You'll find links in this blog to the presentation and demo code shown in that talk.  During the talk, several attendees posted questions on RESTful Web services which I did not have time to answer during the session.  Below, I have tried to answer the remaining questions.

1.  Can you address security in RESTful services?

Since most RESTful Web services rely on HTTP, you can use HTTPS and/or existing HTTP mechanisms to secure your RESTful Web services.  By design, RESTful Web services are lighter-weight that their SOAP counterparts.  Therefore, the kinds of security standards that exist in WS-* specifications are formally available in RESTful settings.  Some RESTful advocates suggest RESTful Web services are actually more secure because they rely on the Internet's existing security infrastructure (see http://www.networkworld.com/ee/2003/eerest.html?page=1).  

In general, you pretty much have to adopt/roll your own with regard to security.  I have started to see some third party (many open source) packages that provide security options for RESTful Web services, but these are not guided by any standard.

2. How is Jersey ( JAX_RS)  different than Servlet based REST mechanism like Restlet. I can see Jersey has AdapterServlet too? Is Jersey  based on Servlet too then?

Jersey is an JAX-RS implementation.  RESTlet is a way to provide RESTful services in Java, but it is not guided by any standard.  In JAX-RS, your RESTful resource services are implemented as annotated POJO's.  In RESTlet, the resource service classes extend ServerResource so some consider this a bit of a burden and intrusive.

The RESTlet group does now have an extension package with allows implements the JAX-RS specification.  See here for more details.

For more comparisons of JAX-RS (and implementations like Jersey) to RESTlets, see the following links:

http://thestewscope.wordpress.com/2008/01/08/rails-jsr311-restlet-and-jersey/

http://stackoverflow.com/questions/80799/jax-rs-frameworks

Per part 2 of your question, yes a servlet does act as a controller to route traffic to the appropriate annotated Jersey resource service.  In that way, both RESTlet and Jersey are similar in their reliance of servlet technology.

3. What is the best way to supply the request=GetCapabilities for REST that one has in SOAP or WMS services to communicate meta-data of REST services?

Many RESTful advocates would say the "conventions" associated with RESTful services makes a capabilities listing unnecessary.  That is, the resource as noun and HTTP method as verb make the services very transparent and easy to work with.

That answer doesn't satisfy many.  There have been home grown solutions like that provided by ebay (see http://developer.ebay.com/products/shopping/) that provide a useful API/description for developers to use.  Others have found a way to wedge RESTful descriptions into WSDL.  However, a relatively new description language called Web Application Description Language (see http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1265367,00.html) is being used in the RESTful community to provide a WSDL-like alternative in the RESTful arena.

4. Can we run a rest web service using https protocol?

Yes

5. How about Spring and REST?

As of Spring 3.0, Spring offers RESTful API, but it is not JAX-RS compliant.  See here for details.  In general, Spring makes use of the annotated MVC controllers to serve as RESTful resources.

6. is there simple/lightweight authentication capabilities with restful web services?

Per #1, again nothing formal is provided, but there are some 3rd party packages sprouting up and all the standard Web authentication mechanisms could be used

7. Is there a way to override the HTTP return error and give more detail?

Yes - to some extent.  For how to modify the message returned from the Jersey implementation see https://jersey.dev.java.net/nonav/documentation/latest/user-guide.html#d4e410.

8. A lot of time was spent on exposing a service using JAX-RS from the server.  On the client, what does REST provide (or not provide) as a 'contract' to be used to define the web service..similar to the WSDL, etc in SOAP (for client-side data binding, etc.).

As mentioned and demonstrated in my talk, JAX-RS does not provide for a client API or contract.  Since REST normally operates on HTTP, one could develop a client using java.....  However, many JAX-RS implementations (like Jersey and RESTEasy) offer client side APIs.  These are non-standard, but do offer a means to more easily communicate with RESTful services independent of implementation.

9. It should be noted to get JSON to output correctly for web-applications (i.e.. {'id':12} instead of {'id':'12'} - supporting primitives as primitives, or handling of arrays properly etc, you need to setup a JAXBContextResolver and dictate the notation to user / type.  JAXB will not 100% give this to you.  You need to map your JAXB annotation to a JSON mapping using a context resolver.   Jersey website/forums do have some notes on this and I have been very successful using Natural Notation with GWT/GXT clients.

Correct and thanks for the providing the extra insight.

10. Twitter's REST API is also pretty good reference if you're trying to grow your own app and don't know where to start. http://apiwiki.twitter.com/Twitter-API-Documentation.

I agree.

11. How do we handle streaming using REST based approach?

There is nothing specific in the current JAX-RS specification about how to handle streaming content.

12. client-side data binding?  Thoughts on Spring 3 MVC as an impl?

Per #5 above, Spring 3 through MVC annotations does provide a RESTful service API but it is not Java spec compliant.  If one was using Spring heavily, I could see an attraction to using the same annotated Spring controller classes for both human Web facing and machine RESTful facing clients.

Thanks for all the great questions, comments and feedback  on our presentation.  I hope you will consider attending our Complete Java Web Services class.