Overview
The REST paradigm has been around for a few years now and still attracts a lot of attention.
The RESTful API can be implemented in Java in a number of ways: you can use Spring, JAX-RS, or just write your own servlets if you’re good and brave enough. All you need is the ability to expose HTTP methods – the rest depends on how you organize them and how you direct the client when calling your API.
As you may realize from the title, this article will focus on JAX-RS. But what does “just an API” mean? It means that the focus here is on clearing up the confusion between JAX-RS and its implementations and offering an example of what a proper JAX-RS web application looks like.
Incorporating it into Java EE
JAX-RS is nothing more than a specification, a set of interfaces and annotations offered by Java EE. And then, of course, we have implementations; some of the best known are RESTEasy and Jersey .
Also, if you ever decide to build a JEE-compatible application server, the folks at Oracle will tell you that, among other things, your server must provide a JAX-RS implementation for use by deployed applications. That’s why it’s called the Java Enterprise Edition Platform .
Another good example of specification and implementation is JPA and Hibernate.
Lightweight wars
So how does all this help us developers? The help is that our deployable components can and should be very thin, allowing the application server to provide the necessary libraries. This applies to RESTful API development as well: the final artifact should not contain any information about the JAX-RS implementation being used.
Of course, we can provide the implementation ( here’s a tutorial on RESTeasy). But then we can no longer call our application a “Java EE app”. If someone comes tomorrow and says ” Ok, it’s time to move to Glassfish or Payara, JBoss has gotten too expensive! ” We might be able to do that, but it will be hard work.
If we provide our own implementation, we have to make sure that the server knows to exclude its own – this usually happens by having a proprietary XML file inside the deployment. Of course, such a file should contain all sorts of tags and instructions that nobody knows anything about except the developers who left the company three years ago.
Always know your server
So far we have said that we should take advantage of the platform we are offered.
Before deciding which server to use, we should look at what JAX-RS implementation (name, vendor, version and known bugs) it provides, at least for production environments. For example, Glassfish comes with Jersey and Wildfly or Jboss comes with RESTEasy.
This of course means a small amount of research time, but this is only supposed to be done once, at the beginning of a project or when migrating it to another server.
Just keep in mind that JAX-RS is a powerful API, and most (if not all) of what you need is already implemented on your web server. You don’t need to turn a deployable module into an unmanageable pile of libraries.