Why use a framework for RESTful services in Java i

问题:

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?

回答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.)

回答2:

JAX-RS is a very well designed API that makes mapping HTTP requests to methods, extracting parameters from various parts of a HTTP request, handling content negotiating, and many other low level tasks very easy.

Using JAX-RS, mainly via Apache CXF, for roughly two years now, I'd always prefer it over plain Servlets.

回答3:

Frameworks are used to make you task more easier. i agree that we can do the same thing by implementing servlets and then parse the url and then implement the basic logic.

Bu if you are using framework like jersey then u don't have to worry about those parsing patterns and other similar tasks. ServletContainer class will take care of this (parsing url in it's service method) and there are lots of other classes also which will make your task easier.

And one more thing we are taking only a one scenario (matching patterns) but when our requirements will grow the same code written by our own servlets will become more complicated and complex.

回答4:

I would go with using Jersey or a library in this case, if it does the following (adds enough value):

• the config for the URL is all self-contained within one file, with the source
• there are no hidden config files or overly verbose configs (e.g. web.xml)
• the parameters are nicely mapped to strongly typed variables (e.g. use of annotations)
• it is not convoluted to get to the values of parameters (e.g. RESTlet)
• the overhead for running the library is low (I have had bad experiences with reflection solutions in other libraries)
• it is well documented
• it is well adopted

In such a scenario, I find that using a library would add value to my project for the effort required to use it. Jersey does seem to mach the requirements quite adequately, although I have not given other frameworks enough investigation yet.