There is no best Java Rest framework. There is also no best Java microservice framework. Different frameworks serve different needs. For example, you might modify an existing application to expose the application’s API as Rest endpoints. Or, you might modify that application to consume somebody else’s REST endpoints. You might develop a new application or a standalone microservice. And you might even write a serverless function meant to reside in the cloud, for example, an Amazon Web Services (AWS) Lambda function. Diverse needs dictate different solutions. In this article, we compare several leading Java Rest frameworks. We then compare several leading microservice frameworks that use those REST frameworks. Although this article does not present any single framework in-depth, it familiarizes you with the major frameworks and provides references to more detailed sources. The following table summarizes the REST Frameworks and Microservice frameworks discussed in this article.
Frameworks Discussed |
---|
Apache CFX |
Jersey |
RESTEasy |
Restlet |
Dropwizard |
Micronaut |
Spring Boot |
Spring (MVC) |
TomEE |
Quarkus |
Framework
Let’s begin by reviewing what a framework is and what it accomplishes. A framework is a foundation of existing code developers builds upon to create his or her application. You use a framework by calling its methods, inheriting its classes, implementing its interfaces, and by supplying callbacks, listeners, and other software constructs. Typically, a framework handles much of the underlying complexities and frees the developer to focus on application logic. Frameworks can be broad and can abstract the complexities of an entire system, for example, Microsoft’s .NET or Apple’s Cocoa framework. Or a framework can be more specialized for smaller domains, for example, REST communication over HTTP. Frameworks can also address problem-specific domains such as finance or medicine. For more detailed information on frameworks, refer to the Wikipedia page: Software framework on Wikipedia.
Frameworks Considered – REST and Microservice
In this article, we limit ourselves to two frameworks: REST frameworks and Microservice Frameworks. REST, or more generally, HTTP communication has considerable low-level complexity. A good REST framework should abstract these low-level details. REST frameworks are an example of a framework that abstracts underlying technical complexity. Microservice frameworks, in contrast, abstract software architecture – a microservice framework makes implementing a microservice architecture easier.
We address both frameworks in this article; however, before we discuss the two framework types, let’s consider how good developers make framework decisions by considering the software’s architecture. Hopefully, even in this day of agile development, you still devote time to considering an application’s architecture before beginning coding. A framework solves an architectural problem, but a framework also usually dictates an application’s structure, and some frameworks provide so much pre-written code that you write very little code of your own. Choose the right framework and your job becomes easier and your application a success. But choose the wrong framework, and your project might fail. Choose no framework, and you are likely to be late and over budget. Selecting the right framework is important.
Software Architecture Decisions
Be careful to not develop a Big Ball of Mud – a software application with no architecture, at least without one you can perceive (Big Ball of Mud). These systems are all too common when a team rushes to develop without investing upfront in software architecture and design – disdainfully calling such efforts as “waterfall.” But, when designing a software system, you must make tough decisions. Make the wrong decision and software might be costlier to create, not meet customer needs, or perform poorly after developed.
Software Architecture Questions
Selecting frameworks is part of the architectural decision-making process. But, before selecting a framework, you should understand your needs. Questions to consider include:
- Is the software primarily client software, server software, or both?
- Are you creating a new application or adding functionality to an existing application?
- Will you deploy a standalone application, deploy your application in an application server like JBoss, or deploy your application as a small independent service?
- What language and technologies are familiar to you and your team?
- Are there any accepted industry standards should your software implement?
- Will you deploy the software in the cloud, for example, as an Amazon Web Services (AWS) Lambda function?
In this article, these questions guide our discussion of the different Java REST and microservice frameworks. However, assume four architectural decisions are non-negotiable in our analysis. First, we must use REST over HTTP. Second, the framework we select must implement the JAX-RS specification (we will consider Spring, however). Third, we must use JSON to format data sent between services. And fourth, we must use the Java programming language. With these four restraints, we narrow the article’s scope to Java REST frameworks and several Java microservice frameworks that make using those REST frameworks easier.
Underlying Technologies
Now that we have reviewed frameworks and software architecture, let’s briefly review the technologies used by these frameworks. Namely, REST, JSON, the JAX-RS specification, and the MicroProfile Rest Client specification. Although not comprehensive, this review should highlight what our framework selections are attempting to accomplish. If any of the topics are unfamiliar, you are encouraged to refer to one of the referenced sources. You cannot expect to make an informed decision on a REST framework or a Java microservices framework if you are unfamiliar with REST or the JAX-RS specification.
Representational State Transfer (REST)
Representational State Transfer (REST) is a web services architectural style where everything is a resource accessible via HTTP. Think of a resource as a noun: a document, image, or an object such as a widget. REST separates the implementation of the client and the server, where each is independent of the other, provided the client knows the format of the server’s message. REST has four basic resource methods: GET, POST, PUT, and DELETE. These commands allow you to act on the defined resources. When combined with Multipurpose Internet Mail Extensions (MIME Types), REST becomes a powerful mechanism for transferring data over simple HTTP. For example, you might request a list of widgets using REST.
GET http://nowhere.com/widgets
Accept: application/json
Or, you might create a new Widget using REST.
POST http://nowhere.com/widgets
Accept: application/json
Body: {“widget”: {“type”:“super”,“color”:”red”}}
The Uniform Resource Locator (URL) identifies the resource of interest. This is called an endpoint. The operation to perform is the HTTP command.
If unfamiliar with REST, there are many references available online. Understanding Java REST frameworks is, of course, predicated on you having a good REST understanding. An excellent starting point is the Representational state transfer Wikipedia page.
JavaScript Object Notation (JSON)
REST resources must follow a standard format if the resource is to be shared between systems. HTML, XML, and JSON are the three formats used by REST, of which JavaScript Object Notation (JSON) is the most widely used. JSON is a simple format for data storage and transport. It uses JavaScript notation to represent objects as attribute and value pairs and groups these objects as arrays. For example, the following is one way to use JSON to represent three widgets as stock.
{“stock”:
[
{“type”:”super”, “color”:”red”},
{“type”:”normal”,“color”:”green”},
{“type”:”super”,”color”:”purple”}
]}
Or alternatively,
{“stock”:
[
{"Widget":{“type”:”super”, “color”:”red”}},
{"Widget":{“type”:”normal”,“color”:”green”}},
{"Widget":{“type”:”super”,”color”:”purple”}}
]}
The MIME type for JSON is application/JSON and .json is the filename extension. REST services use this MIME type to identify the resource being transferred by the REST service. JSON has mostly replaced XML as the data format for resources transmitted over RESTful services; this article assumes JSON is the message framework used when comparing frameworks. If you need a better understanding of JSON, refer to one of the references at the end of this article. But a good starting point is the JSON Wikipedia page.
Java API for RESTFul Web Services (JAX-RS)
Other than Spring, if a Java Rest framework does not implement the JAX-RS specification, then it is probably not going to gain a wide user base. JAX-RS is a specification developed by the Java Community Process (JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services) and is the defacto standard for developing Java Rest applications. JAX-RS is an application program interface (API) that specifies how to create REST web services when using Java. The specification uses Java annotations to provide a simple specification for developing web service endpoints and clients that support the Representational State Transfer (REST) architecture pattern. A vendor must implement the JAX-RS interfaces and annotations if claiming a JAX-RS compliant framework.
JAX-RS Service Example
Consider the following example of JAX-RS. Suppose we had the following WidgetRestService REST resource. As an aside, note that the resource assumes we are using a JSON library to serialize/deserialize objects into/from JSON.
@Path(“/widget”)
Public Class WidgetRestService {
@GET
@Path(“/{id}”)
@Produces(MediaType.APPLICATION_JSON)
Widget getWidget(@PathParam(“id”) String id) { … }
}
The REST framework implementing the JAX-RS specification handles the complexities for us in the preceding code, requiring us to only know how to use the annotations properly.
JAX-RS Client Example
Now consider the code we would write using JAX-RS in client software consuming the WidgetRestService endpoint above. Obtaining a Widget using JAX-RS might appear as follows.
Client myClient = ClientBuilder.newClient();
Widget myWidget = client.target(“http://widgets/rest/getWidget”).path(id)
.request(MediaType.APPLICATION_JSON).get(Widget.class);
Again, the REST framework implementing JAX-RS frees us to worry about our application logic, as the complexities of constructing a URL, calling that URL, obtaining the data from the URL, and translating it from JSON to a Java object are hidden. Note that in this code, as with the server code, we are assuming a registered JSON library that does the serialization/deserialization for us.
RESTFull Architecture Pattern
Now that we have reviewed REST, JSON, and JAX-RS, let’s revisit RESTFull architecture. An application that communicates using a RESTFull web service needs to perform one basic task, format requests and responses to the standard HTTP messaging protocol. When combined with a JSON library, a RESTFull web service must serialize and deserialize objects from JSON. The web service provider (the server) typically translates a Java data object into JSON and then transmits it to a client.
RESTFull Web Service Architecture Example
In the following figure, a Widget is serialized into JSON by a JSON processor. The JSON is then transmitted to the client as an HTTP Response. The REST framework handles the HTTP communication complexities.

RESTFull Web Service Consumer Example
The RESTFull web service consumer (the client) receives the JSON as an HTTP Response from the server and translates it into a Java object. For example, in the following figure the service receives an HTTP Response and deserializes it into a Widget object.

Of course, the roles also reverse, as clients must transmit JSON REST requests and servers must translate those incoming requests. But the two constants are a JSON processor that serializes and deserializes Java objects and a REST Implementation responsible for abstracting the details of sending and receiving REST messages over HTTP.
Leading JAX-RS REST Frameworks
REST frameworks abstract the complexity of the underlying HTTP protocol from you. It also implements methods that make using REST easier. Here, except for Spring, we limit ourselves to Java REST frameworks that implement the JAX-RS specification. But, even when developing a Spring application, you can use JAX-RS, as discussed later in this article.
Apache CFX
Apache CFX (cxf.apache.org) is an open-source framework for building web services that are supported by the Apache Software Foundation. CFX is fully compliant with all major versions of the JAX-RS specification. Apache CFX supports JSON through the Jettison library (Jettison on GitHub).
Jersey
The Jersey RESTful web services framework is the reference implementation for the JAX-RS specification. It was originally developed by Sun, passed on to Oracle, and currently resides with the Eclipse foundation (Eclipse Jersey). Jersey is available standalone or as part of the Glassfish application server. Jersey supports JSON through the MOXy library (EclipseLink MOXy).
RESTEasy
RESTEasy is a Red Hat/JBoss implementation of JAX-RS (RESTEasy – JBoss Community). It comes pre-included with the JBoss Enterprise Application Server and the WildFly application server. Quarkus, discussed later in this article, also bundles RESTEasy as part of its framework. And Spring Boot, also discussed later in this article, has a starter bundle that pre-packages and configures RESTEasy as its REST processing library. RESTEasy supports JSON through the Jettison or Jackson JSON libraries.
Restlet
The Restlet framework, self-proclaimed as “the most widely used open-source solution”, is an opensource JAX-RS implementation developed by Talend (Restlet Framework). Restlet supports JSON through an extension, org.restlet.client.ext.JSON representation or an extension supporting the Jackson JSON library.
Spring Framework (Spring MVC)
The Spring Framework’s Spring MVC is the black sheep of the REST Frameworks, as it does not implement the JAX-RS specification. Instead, Spring uses its framework to support REST. However, as Spring is arguably the most popular framework for developing Java Enterprise Applications, Spring must be considered despite its noncompliance. However, if you have Spring experience, then you know it is easily modifiable to replace Spring’s REST API with a JAX-RS compliant framework.
Rather than using JAX-RS annotations, Spring defines its own. In Spring, you annotate a REST service class with the @RestController annotation. You then map methods in the class to the relevant REST endpoint resource and command using the @GetMapping, @PostMapping, @DeleteMapping, and @PutMapping annotations. For example, the following code snippet illustrates a Spring rest controller for working with Widgets.
@RestController
public class WidgetRestController {
@GetMapping("/rest/widget/{id}")
public Widget getWidger(@PathVariable("id") int id) { ... }
@GetMapping("/rest/widgets")
public List<Widget> getWidgets() { ... }
@PostMapping("/rest/widget/create")
public Widget createWidget(@RequestBody Widget widget) { ... }
@DeleteMapping("/rest/widget/delete/{id}")
public void deleteWidget(@PathVariable("id") int id) { ... }
}
Spring uses the Jackson library to support JSON although it is easily configured to use other JSON libraries. For more information on Spring MVC refer to the documentation (Spring MVC Documentation).
Other Frameworks for REST (Simple Clients)
But what if you just want to consume a REST endpoint in your application and do not need a full-blown framework? There are simpler alternatives to the JAX-RS frameworks discussed above. Here we consider two frameworks, Unirest-Java and OkHttp that are lightweight and simple to use if you have relatively simple requirements.
Unirest Java Library
Unirest is a lightweight HTTP library developed by Mashape. It is not a REST framework, but it supports JSON, is easy to use, and has the most major features found in a REST framework. UniRest simplifies using REST in client applications. For example, getting a String using a UniRest is as simple as the following.
String myString = Unirest.get(“http://widget.com/widget”).asString();
Unirest also supports JSON by including the Jackson library, and can serialize and deserialize Java objects to JSON. You are not even required to write the code to handle the response object, as UniRest handles the serialization/deserialization for you.
Widget myWidget = Unirest.post(“http://widget.com/widget”).queryString(“id”,”123”).asObject();
The following screenshot illustrates just how easy it is to consume a REST service using Unirest. This is the Crime Data API on RapidAPI (rapidapi.com/jgentes/api/crime-data). The webpage shows the endpoint, example data returned, and other information needed to use the API. However, It also provides code snippets for most languages. Notice how simple it is to call the service when using UniRest.

If your application is a client application that only needs to consume a few REST endpoints, then UniRest is a good lightweight alternative to a full-blown REST framework.
OkHttp
OkHttp is another HTTP client that is easy to use. The Android platform includes the library for making HTTP calls from Android mobile devices. The library does not include a JSON parser, so you must do a bit more work than when using UniRest. However, you can add a JSON library such as Jackson to your project and can serialize/deserialize objects using only a few more lines than when using UniRest.
For example, the following code snippet illustrates using Jackson to translate the response body text into a Widget Java object.
ObjectMapper objectMapper = new ObjectMapper();
ResponseBody responseBody = client.newCall(request).execute().body();
Widget myWidget = objectMapper.readValue(responseBody.string(), Widget.class);
Selecting a Framework
Nobody ever fired an architect for selecting a standard with buy-in from all major vendors. Selecting JAX-RS is the prudent choice if developing a Java application. Of course, if your needs are limited to consuming a few REST endpoints, consider something simple such as Unirest-Java or OkHttp. If housing your application in an application server, consider the REST framework included with the server.
Application Server
Application servers are the venerable powerhouses of Java web applications and arguably became the primary reason for Java’s continued popularity post-applet days. An application server provides a server and framework(s) for running web applications. Popular ones include: JBoss EAP, WildFly, WebSphere, Weblogic, GlassFish, Tomcat, Jetty, JOnAs, and Resin. And of course, these servers implement the Java Platform, Enterprise Edition (JEE) specification originally developed by Sun and now Oracle. Despite the popularity gain of more recent microservice frameworks, most Java web applications today still reside in a JEE Application Server. Table two lists the most popular application servers and their included REST framework.
Application Server | Rest Framework Included |
---|---|
JBOSS EAP, Wildfly | RESTEasy |
WebSphere | proprietary |
Weblogic | Jersey |
Glassfish | Jersey |
Jetty | - |
Tomcat | - |
JOnAS | Jersey |
Resin | - |
Popular JEE servers and included REST framework.
If developing a REST API for an existing application, or an application that must reside on an application server, then select the REST Framework that comes pre-bundled with the server. If no Rest Framework is included, then you probably shouldn’t be using the server in the first place; however, you should be able to add one easily to your application.
Microservice Frameworks
Developing a new application provides considerably more flexibility in framework choice. The JAX-RS frameworks already discussed do one and only one thing – provide and consume REST services. However, there are larger frameworks that incorporate the JAX-RS frameworks that make developing a REST application easier. The four discussed here are Dropwizard, Micronaut, Spring Boot, and Quarkus. All four are excellent decisions, although Spring Boot is the most ubiquitous of the four frameworks being used today.
Microservice
Microservices is an architectural style that serves as an alternative to large applications. For example, if you needed to develop a Widget Tracking application, a more traditional approach is to design, well, a Widget Tracking application. That application might involve other systems, so you might choose a Service Oriented Architecture for your application. These tasks would be broken down into different services, but they would all reside in the same application. In a microservices architecture, an application is composed of loosely coupled services. Typically those services are independent of one another and in many situations reside in different systems.
Suppose the Widget Corporation has three distinct systems for different business areas, the factory production system, warehouse inventory system, and the store inventory system. Now suppose you needed an application that used all three systems. Also assume your application needs to access an external service, such as the AirportsFinder API housed on RapidAPI. Let’s compare an SOA solution to a microservices solution.
SOA Architecture Example
Traditional SOA architecture focuses on developing a system of service services that connected with these different systems into a unified application. In figure 4, for example, the Widget Corporation creates a single service bus that provides an interface to its disparate systems and external system. Clients then access the service bus exposed services as needed. However, the important point is all services reside in the same application, the service bus.

Microservice Architecture Example
A microservice architecture, in contrast to an SOA architecture, decomposes a service bus into individual fine-grained applications. For instance, in the following figure representing an example microservice architecture, each domain-specific application has as many independent services as needed. Those services are fine-grained and perform a single function. Those services could be combined into one application or multiple applications, depending upon need. Moreover, each microservice could be housed on separate physical servers. How fine-grained your microservice architecture should be is an architectural decision only you can make. However, the important point is that all the services reside in different applications, not a monolithic service bus. Moreover, as illustrated in the figure below, client applications access external systems directly, not via an internal service bus.

REST is an obvious choice for intercommunication between those independent microservices. Let’s now look at several of the leading Java microservice frameworks and how they integrate a Java REST framework. For the definitive explanation of a microservice architecture, refer to the article “Microservices: a definition of this new architectural term” available at martinFowler.com.
Leading Microservice Frameworks
The leading Java Microservice frameworks are Dropwizard, Micronaut, Spring Boot, TomEE, and Quarkus. Let’s briefly consider each framework.
Dropwizard
Dropwizard is an amalgamation of other Java frameworks to provide a complete framework for developing RESTFul web services. The framework integrates many robust pre-existing libraries such as Hibernate, Jersey, and other frameworks into one larger framework with the intention of making development easier. It uses Jersey as its REST Framework. For more information, refer to the Dropwizard website (dropwizard.io).
Micronaut
Micronaut describes itself as “a modern, JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications.” It claims a “monumental leap in startup time, blazing-fast throughput, [and] minimal memory footprint.” It accomplishes these claims by using the GraalVM which compiles Java applications to native machine code. The framework also avoids runtime reflection. However, the framework is not JAX-RS compliant. For example, you must import Micronaut specific implementation classes rather than JAX-RS interfaces.
import io.micronaut.http.MediaType;
import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;
import io.micronaut.http.annotation.Produces;
Note that at the time of this writing, there is a project adding support for JAX-RS to Micronaut (Micronaut JAX-RS).
Spring Boot
Spring Boot is a Java framework that is built using the venerable Spring framework. You use the framework for creating stand-alone microservices. Spring Boot helps ease that development by minimizing configuration details. It consists of an embedded Tomcat or Jetty application server and other dependencies depending upon project needs. These pre-packaged bundles are called “starter projects” and bundle all needed dependencies into one package. The framework also offers an online project starter called the “Spring Initializr,” available at the start.spring.io website which allows you to configure a new project and then download your customized Spring Boot package.

The Spring Boot framework supports either Spring REST or JAX-RS by including the Jersey framework.

Quarkus
Quarkus touts itself as “a Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.” Quarkus uses RESTEasy as its JAX-RS implementation and either Jackson or JSON-B as its JSON processor. Like Spring Boot, Quarkus has an application configuration page at the code.quarkus.io website.

Apache TomEE
Apache TomEE is a microservice framework built around the Apache Tomcat web server. It also implements the Eclipse foundation Microprofile. Microprofile is an open specification designed to optimize JEE to support microservices supported by the Eclipse Foundation (Microprofile.io). You can create a starter TomEE project at the MicroProfile Starter webpage (start.microprofile.io).

MicroProfile
As a final consideration, a newer effort is the Eclipse MicroProfile, which optimizes JEE for microservices. The current version, as of the time of this writing in 2020, is Eclipse MicroProfile 3.3. Runtimes supporting the MicroProfile include Payara Micro, KumuluzEE, Open Liberty, Helidon, TomEE, WildFly Swarm, Thorntail, and Quarkus. For more information, refer to the MicroProfile website (microprofile.io).
Microservice Framework Comparison
The following figure summarizes the microservice frameworks and REST frameworks summarized in this article. All the major frameworks support JAX-RS except for Micronaut and Spring. Of course, as mentioned earlier, you can add JAX-RS support to either.

Quarkus is much smaller than Spring-boot and TomEE and has a much faster startup time. If compiled to native code, then Quarkus has a size and startup time comparable to native executables. Quarkus performs so much better than the competing platforms it is worth considering for a moment.
You can run your code as bytecode in a JVM or as a native binary when using Quarkus. The resulting native executable throughput trounces its main competitor Spring Boot and/or the Spring Framework. For a good comparison, refer to this article comparing the two (Quarkus vs Spring). There are many other sources online attesting to tremendously faster speed and smaller size of Quarkus when packaged as a GraalVM native image.
Decision-Making Path
The following two figures illustrate how your decision making might proceed. There is no single path to an architectural decision, this is just an example path you might take.

For client applications that only consume pre-existing REST endpoints, consider if your application’s REST needs are simple or complex. If simple, consider using a smaller library such as UniRest. But if complex, any one of the JAX-RS compliant libraries are probably acceptable candidates.
When creating a service layer, a safe selection is whatever JAX-RS compliant REST framework comes prepackaged with the application server or framework you are using. A Spring application, you can either use Spring’s REST API or add a JAX-RS compliant Java framework to Spring. Alternatively, you could create microservices. The following diagram illustrates one path your decision-making might take when considering a microservice framework/architecture.

If developing microservices without using a microservices framework, and using an application server, then select the JAX-RS compliant REST framework included with the server. Otherwise, any of the REST frameworks will probably work for your needs.
If developing microservices using a framework and it needs to be very fast and very small, choose Quarkus. If developing a Java REST application for deployment in a cloud provider such as AWS, then select Quarkus compiled as a GraalVM native image (Lightweight cloud-native Java applications). Otherwise, any of the other microservice frameworks will do. Although, of all the frameworks, Spring Boot has the most industry acceptance.
Summary: Best Java Frameworks for REST APIs
This article contained many selections for a REST Framework. Generally, the advice is straightforward on which is the “best” framework – there is no “best” framework. The framework should implement the JAX-RS specification and easily integrate it with a JSON processor. Table four summarizes the frameworks considered in this article.
JAX-RS | Included REST Framework | Complete Ecosystem | |
---|---|---|---|
Apache CFX | Yes | - | - |
Dropwizard | Yes | Jersey | Yes |
Jersey | Yes | - | - |
Micronaut | No | - | Yes |
RESTEasy | Yes | - | - |
Restlet | Yes | - | - |
Spring Boot w/Jersey | Yes | Jersey | Yes |
Spring (MVC) | No | - | Yes |
TomEE | Yes | Apache CFX | Yes |
Quarkus | Yes | RESTEasy | Yes |
Summary of REST frameworks and Microservice frameworks
When using an application server, make your life easier and select the one that comes bundled with the server. If developing a REST client, choose between a JAX-RS or simpler client such as UniREST depending on your project’s complexity. If starting a new project, particularly microservices in the cloud, consider Quarkus as your larger framework. However, All four frameworks make developing JAX-RS compliant RESTfull applications much easier. There is no one best decision; however, this article should provide a starting point for further research. Good luck! Check out Rapid‘s API Hub which lets developers easily find and connect to thousands of APIs.
FAQ
What is the best Java Framework?
There is no best Java Rest framework. There is also no best Java microservice framework. Different frameworks serve different needs. For example, you might modify an existing application to expose the application’s API as Rest endpoints. Or, you might modify that application to consume somebody else’s REST endpoints. You might develop a new application or a standalone microservice.
What is a Java Framework?
Let’s begin by reviewing what a framework is and what it accomplishes. A framework is a foundation of existing code developers builds upon to create his or her application. You use a framework by calling its methods, inheriting its classes, implementing its interfaces, and by supplying callbacks, listeners, and other software constructs. Typically, a framework handles much of the underlying complexities and frees the developer to focus on application logic. Frameworks can be broad and can abstract the complexities of an entire system, for example, Microsoft’s .NET or Apple’s Cocoa framework. Or a framework can be more specialized for smaller domains, for example, REST communication over HTTP. Frameworks can also address problem-specific domains such as finance or medicine.
What are the leading Java Rest Frameworks?
Apache CFX, Jersey, RESTEasy, Restlet
Hi James!
Did you ever have a chance to look at Bootique? It would be a microservices framework for Java according to your classification. It’s free, open-source, and often much faster at startup than Springboot.
(Disclosure: I work for the company that created it).
Excellent article, thanks for the insights. Got a quick overview and comparison of all frameworks. On a side note, Apache CFX seems like typo of CXF?
Thanks for the helpful article. Did you ever consider including the Play Framework in this list?
Less a Framework and more a Tookit, but I’m a big fan of using vert.x for reactive micro-service development. Incredibly fast and unopinionated.
Very well put article. It cleared most of my dilemma regarding different frameworks and micro services. I would recommend this article to people for sure.
I would love another article comparing RESTful with SOA architecture.