Are there use cases in which traditional Servlets still have design advantages over JAX-RS?

Viewed 758

Recently I started looking for a "Sinatra-clone", an ultralight web framework for Java. Something that allows you to define all of your URL-routing in one clean block of code, and maybe even write the implementations right there for simple cases. As opposed to Servlets... where you either use XML or else scatter annotations across the entire codebase, and need entirely separate Servlet classes for even the most simple route handlers.

Most of the options are either really excessive and/or counter to this approach (e.g. Spring, JEE), or else push you toward using Scala or Groovy rather than pure Java (e.g. Scalatra, Play, Ratpack). Spark and Vert.x are interesting, and I'm tinkering with both in my personal projects, but I'd like to see a bit more maturity and longevity before pushing them for production projects at my job.

Then it occurred to me that JAX-RS basically encompasses everything that I'm talking about. So far I've only used Jersey in the context of RESTful "services"... returning JSON to AJAX calls, or XML to other back-end systems. However, there's no reason why a JAX-RS method can't also return HTML (or whatever) to a browser, and replace the need for a full Servlet class. JAX-RS gives you access to session state if you want it, and tools such as filters/interceptors that you would need for non-trivial applications. If you add some kind of template library (e.g. Velocity, FreeMarker) then you pretty much have the gist of Sinatra in a widely-supported Java standard. JAX-RS 2.0 even gives you asynchronous HTTP (i.e. long-polling, server-side push) that seems easier than the Servlet 3.x version.

So I'm curious why at this point you might still want to use traditional Servlets at all? Obviously people have their subjective preferences... some people might simply prefer having a separate class for each route handler, or want the lowest learning curve possible when onboarding new developers, etc. However, OBJECTIVELY speaking, what functionality (if any) is offered by Servlet 3.x that is simply missing from JAX-RS (or might be more painful to use)? In choosing between traditional Servlets or JAX-RS for a web application, are there still use cases for which Servlets are unquestionably the more appropriate design choice?

1 Answers

Well, this is an opinion-based answer which I would have rather written in form of a comment if it wouldn't have been too long. I argue that in the end, Java developers do not want to use frameworks that are based on the servlet specification at all. If you are looking for discussions on the servlet API you will find this quote in one or another way:

The servlet API is built on the assumption that Java is more important than the web but that is not true. The web is more important than Java.

I would agree that JAX-RS offers a nicer tool set to work with than the servlet API. But so does Spring MVC. And there are other adapters out there that give a nicer general interface to web development than the servlet specification. It is for example way easier to built a proper web application with Spring MVC but still, you usually plug in other frameworks like thymeleaf or what ever you prefer. So Spring MVC is itself rather a raw kind of web framework which offers a general interface rather than a full web framework.

If you are looking at the general trend of web application frameworks out there, I believe that the future lies in frameworks that ignore the servlet specification such as Play!. In the end, the web is too much about scalability and lean use of resources. It is about embracing the web (as the quote implies) rather than wrapping it into a Java API/SPI. Because of that, I do not believe that a JAX-RS base web application could ever come near the possibilities that Play! already gives you to make writing web applications as easy as possible.

That said: I believe that you are right that people want to find something simpler than the servlet API on the long run. I do however not believe that it will be something like JAX-RS what is usually implemented on top of that API, I believe it will be something that comes closer to native HTTP-interfaces like demonstrated with Play! (which has a Java API)

Related