24

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.

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?

Community
  • 1
  • 1
avanderw
  • 675
  • 1
  • 7
  • 22
  • Actually Jersey is the reference implementation of JAX-RS. So I'd call it the pioneer, not Restlet. –  Jan 20 '12 at 09:30
  • Your edit makes your question answer itself. If you just want to say "Hello World", you don't need JAX-RS. But who just wants to do that? –  Jan 20 '12 at 09:32
  • I should have referenced wikipedia there, personally I am wary of calling things pioneers – avanderw Jan 20 '12 at 09:33
  • 2
    If that's “all” you're doing, why bother with servlets at all? After all, with just GET you shouldn't be changing any state anywhere (well, not state worth the name; server logs don't count). – Donal Fellows Jan 20 '12 at 09:39
  • Donal I do not follow... What handles the GET request then? – avanderw Jan 20 '12 at 09:43

4 Answers4

14

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

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • When would using regular servlets instead of jersey be appropriate? Should handling doPost in a httpservlet never be done? – jontro Oct 22 '13 at 12:50
  • 1
    @jontro When you like doing everything by hand? I'm not convinced that there's really a good reason unless you've got a desperate need to keep the number of libraries down. – Donal Fellows Oct 23 '13 at 18:46
7

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.

  • But is the time to learn, implement, understand for each developer worth it. I mean does it save time? Is it really more simple? If it is just about extracting parameters, then surely it is easier to stay closer to the Java standard. It would be rather simple to extract parameters in a servlet. I feel that it is potentially too much added complexity for the value it provides. – avanderw Jan 20 '12 at 09:00
  • You don't just want to extract parameters. You want to set HTTP response codes, map incoming and outgoing bodies to objects, and other stuff. Yes, JAX-RS helps with this. –  Jan 20 '12 at 09:02
  • 2
    @avanderw Maybe your experience is only with simple webapps, because I know from mine that it really helps a lot with more complex applications. Doing all that stuff directly at the level of a servlet would be a lot of work, but JAXRS lets you focus much more on the resources within your application. (Not that I'd claim it's perfect — some surprising things are still very awkward — but it definitely makes things a lot easier.) – Donal Fellows Jan 20 '12 at 09:20
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.

Prateek Sharma
  • 346
  • 3
  • 12
  • This is just my point, why use a sledgehammer to hammer in a nail. If the framework is easy enough to adopt then you should be able to go from vanilla to the framework with more ease than from another framework, when the need arises. Why take the whole kitchen sink when all you need is the tap? – avanderw Jan 20 '12 at 09:25
  • Actually JAX-RS is an API while CXF, Jersey, RESTEasy are implementations. They all have their strong and weak sides, for example how easy they integrate with Spring. But I would definitely recommend using JAX-RS. –  Jan 20 '12 at 09:27
2

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.

Community
  • 1
  • 1
avanderw
  • 675
  • 1
  • 7
  • 22