Why use a framework for RESTful services in Java instead of vanilla servlets

Question

I know there are a few questions regarding the libraries you can use to do RESTful services in Java, but what is the value in using them against vanilla implementations. I mean, if i was looking to create the url structure described by Wim

• www.example.com/images
• www.example.com/images/id/num
• www.example.com/images/tag/num
• www.example.com/images/tag/num/num/num

Would it not be easier (for future developers) and faster (to implement and learn) to map the url pattern /images to a servlet and have a line or two that parses the url for the parameters instead of learning, implementing and configuring one of these libraries to do it for you.

• Apache CXF
• Jersey (popular)
• Restlet (pioneer of JAX-RS)
• RESTEasy

Essentially what I am asking is... What is the value in using a RESTful Java framework? Would it not be adding a lot of complexity, in the implementation, for a simple problem?

EDIT: This jersey code is handled very neatly and everyone should know how to do it in servlet form if they are looking into libraries to do it for them.

@Path("/helloworld") public class HelloWorldResource {      // The Java method will process HTTP GET requests     @GET     // The Java method will produce content identified by the MIME Media     // type "text/plain"     @Produces("text/plain")     public String helloWorld() {         // Return some cliched textual content         return "Hello World";     } } 

If all you are going to be doing is a "service" that returns text that is driven by URL parameters, so plain text returns, is a framework necessary?

Answer 1

Would it not be easier (for future developers) and faster (to implement and learn) to map the url pattern /images to a servlet and have a line or two that parses the url for the parameters instead of learning, implementing and configuring one of these libraries to do it for you.
…

Easier? It's certainly not easier to write — you've got to do all the path extraction yourself and all the method handling and all the content type negotiation (in both directions) and all the cookie handling and the object deserialization/serialization thunks and … well, lots of low-level stuff that would all need testing and debugging — or easier to maintain either, since the JAX-RS interface lets you operate at the level of resources (the natural characterization of RESTful webapps) instead of requests; with much experience, maintenance is easiest when the gap between conceptual model and implementation is smallest. It's also not faster to implement (because the low-level implementations of JAX-RS have already been tested and debugged for you; less for you to do) and the cost of learning it isn't very high as it is a mostly declarative API with very few surprises.

OK, these benefits might not seem so much when you're only dealing with simple webapps. After all, you can hack something out in very little time and put the resulting lash-up online. You'll then have to pray that you got it right without significant unexpected avenues for exploits or denial-of-service attacks. And the maintenance programmers will have to understand just what those regular expressions you've sprayed through the code do (Good Luck With That!) when adding small features or fixing bugs. But as the webapp gets larger, the benefit of having a tested library to handle all the low-level stuff really does win out.

(Before you ask, some of the libraries you mention will merrily install themselves as servlets; this allows your code to just describe the business logic of the servlet and declare how mapping to the wire is done in abstract terms. That's just enormously easier.)