We're going to be talking a lot about a new REST-based NixMash Cloud application we're building, but before diving in to the application we wanted to review some of the technologies that make up a RESTful Application: JAX-RS, Jersey and Jackson.
What is REST?
REST stands for Representational State Transfer. In a REST-based architecture you typically have a REST server which provides access to resources and a REST client which accesses and modifies those REST resources.
In a REST-based architecture everything is a resource, and every resource should support the HTTP common operations, PUT, GET, POST and DELETE. Every interaction with a resource is stateless, meaning the server does not store session state on the server side. Any session state is stored on the client. That is where the "ST" in REST comes from, State Transfer. You transfer the state around instead of having the server store it.
Java defines REST support in the Java Specification Request JSR 311. This specification is called JAX-RS, the Java API for RESTful Web Services. JAX-RS uses annotations for implementing RESTful web services, annotating classes and methods with information that enables a runtime to expose them as resources.
Jersey is the implementation of the JAX-RS specification. The Jersey framework extends the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development. With Jersey as our friendly interface to the HTTP stack we can delegate the plumbing details to the framework.
Jackson is a framework with powerful data binding capabilities to serialize custom java objects to JSON and deserialize JSON back to java objects. It supports many other data types besides JSON. You can think of Jersey as the transport mechanism where Jackson is at the ready for binding and packaging data objects. Like Jersey, Jackson functions on both the server and client side.
HATEOAS, pronounced "HATE-O-A-S", is an abbreviation for Hypermedia As The Engine Of Application State. It is a REST architecture structure where a client interacts with the networked application entirely through hypermedia provided dynamically by the application. A REST client enters the application through a simple fixed URL and needs no prior knowledge about how to interact with it. All actions the client can take are discovered within resource representations returned from the server based the representation's media type, which makes the interaction hypermedia-driven.
Source Code for this Post
Concepts discussed in this post and others in our Microservices Series is found in NixMash Microservices on GitHub.