Since a long time the Java Script Object Notation [1] become as a lightweight standard to replace XML for information exchange between heterogeneous systems. Both technologies XML and JSON closed those gap to return simple and complex data of a remote method invocation (RMI), when different programming languages got involved. Each of those technologies has its own benefits and disadvantages. A good designed XML document is human readable but needs in comparing to JSON more payload when it send through the network. For almost every programming languages existing plenty implementations to deal with XML and also JSON. We don’t need to reinvent the wheel, to implement our own solution for handling JSON objects. But choosing the right library is not that easy might it seems.
The most popular library for JSON in Java projects is the one I already mentioned: Jackson [2]. because of its huge functionality. Another important point for choosing Jackson instead of other libraries is it’s also used by the Jersey REST Framework [3]. Before we start now our journey with the Java Frameworks Jersey and Jackson, I like to share some thoughts about things, I often observe in huge projects during my professional life. Because of this reason I always proclaim: don’t mix up different implementation libraries for the same technology. The reason is it’s a huge quality and security concern.
The general purpose for using JSON in RESTful applications is to transmit data between a server and a client via HTTP. To achieve that, we need to solve two challenges. First, on the server side, we need create form a Java object a valid JSON representation which we can send to the client. This process we call serialization. On the client side, we do the second step, which is exactly the opposite, we did on the server. De-serialization we call it, when we create a valid object from a JSON String.
In this article we will use on the server side and also on the client side Java as programming language, to deal with JSON objects. But keep in mind REST allows you to have different programming languages on the server and for the client. Java is always a good choice to implement your business logic on the server. The client side often is made with JavaScript. Also PHP, .NET and other programming Languages are possible.
In the next step we will have a look at the project architecture. All artifacts are organized by one Apache Maven Multi-Module project. It’s a good recommendation to follow this structure in your own projects too. The three artifacts we create are: api, server and client.
- API: contain shared objects which will needed on the server and also client side, like domain objects and interfaces.
- Server: producer of a RESTful service, depends on API.
- Client: consumer of the RESTful service, depends on API.
Inside of this artifacts an layer architecture is applied. This means the access to objects from a layer is only allowed to the direction of the underlying layers. In short: from top to down. The layer structure are organized by packages. Not every artifact contains every layer, only the ones which are implemented. The following picture draws an better understanding for the whole architecture is used.
The first piece of code, I’d like to show are the JSON dependencies we will need in the notation for Maven projects.
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>${version}</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<version>${version}</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>${version}</version>
</dependency>Listing 1
In respect to the size of this article, I only focus how the JSON object is used in RESTful applications. It’s not a full workshop about RESTful (Micro) Services. As code base we reuse my open source GitHub project TP-ACL [4], an access control list. For our example I decided to sliced apart the Role – Functionality from the whole code base.
For now we need as first an Java object which we can serialize to an JSON String. This Domain Object will be the Class RolesDO and is located in the layer domain inside the API module. The roles object contains a name, a description and a flag that indicates if a role is allowed to delete.
@Entity
@Table(name = "ROLES")
public class RolesDO implements Serializable {
private static final long serialVersionUID = 50L;
@Id
@Column(name = "NAME")
private String name;
@Column(name = "DESCRIPTION")
private String description;
@Column(name = "DELETEABLE")
private boolean deleteable;
public RolesDO() {
this.deleteable = true;
}
public RolesDO(final String name) {
this.name = name;
this.deleteable = true;
}
//Getter & Setter
}
Listing 2
So far so good. As next step we will need to serialize the RolesDO in the server module as a JSON String. This step we will do in the RolesHbmDAO which is stored in the implementation layer within the Server module. The opposite direction, the de-serialization is also implemented in the same class. But slowly, not everything at once. lets have as first a look on the code.
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
public class RolesDAO {
public transient EntityManager mainEntityManagerFactory;
public String serializeAsJson(final RolesDO role)
throws JsonProcessingException {
ObjectMapper mapper = new ObjectMapper();
return mapper.writeValueAsString(role);
}
public RolesDO deserializeJsonAsObject(final String json, final RolesDO role)
throws JsonProcessingException, ClassNotFoundException {
ObjectMapper mapper = new ObjectMapper();
return (RolesDO) mapper.readValue(json, Class.forName(object.getCanonicalName()));
}
public List<RolesDO> deserializeJsonAsList(final String json)
throws JsonProcessingException, ClassNotFoundException {
ObjectMapper mapper = new ObjectMapper();
return mapper.readValue(json, new TypeReference<List>() {});
}
public List listProtectedRoles() {
CriteriaBuilder builder = mainEntityManagerFactory.getCriteriaBuilder();
CriteriaQuery query = builder.createQuery(RolesDO.class);
Root root = query.from(RolesDO.class);
query.where(builder.isNull(root.get("deactivated")));
query.orderBy(builder.asc(root.get("name")));
return mainEntityManagerFactory.createQuery(query).getResultList();
}
}Listing 3
The implementation is not so difficult to understand, but may at this point could the first question appear. Why the de-serilization is in the server module and not in the client module? When the client sends a JSON to the server module, we need to transform this to an real Java object. Simple as that.
Usually the Data Access Object (DAO) Pattern contains all functionality for database operations. This CRUD (create, read, update and delete) functions, we will jump over. If you like to get to know more about how the DAO pattern is working, you could also check my project TP-CORE [4] at GitHub. Therefore we go ahead to the REST service implemented in the object RoleService. Here we just grep the function fetchRole().
@Service
public class RoleService {
@Autowired
private RolesDAO rolesDAO;
@GET
@Path("/{role}")
@Produces({MediaType.APPLICATION_JSON})
public Response fetchRole(final @PathParam("role") String roleName) {
Response response = null;
try {
RolesDO role = rolesDAO.find(roleName);
if (role != null) {
String json = rolesDAO.serializeAsJson(role);
response = Response.status(Response.Status.OK)
.type(MediaType.APPLICATION_JSON)
.entity(json)
.encoding("UTF-8")
.build();
} else {
response = Response.status(Response.Status.NOT_FOUND).build();
}
} catch (Exception ex) {
LOGGER.log("ERROR CODE 500 " + ex.getMessage(), LogLevel.DEBUG);
response = Response.status(Response.Status.INTERNAL_SERVER_ERROR).build();
}
return response;
}
}Listing 4
The big secret here we have in the line where we stick the things together. As first the RolesDO is created and in the next line the DAO calls the serializeAsJson() Method with the RoleDO as parameter. The result will be a JSON representation of the RoleDO. If the role exist and no exceptions occur, then the service is ready for consuming. In the case of any problem the service send a HTTP error code instead of the JSON.
Complex Services which combine single services to a process take place in the orchestration layer. At this point we can switch to the client module to learn how the JSON String got transformed back to a Java domain object. In the client we don’t have RolesHbmDAO to use the deserializeJsonAsObject() method. And of course we also don’t want to create duplicate code. This forbids us to copy paste the function into the client module.
As pendant to the fetchRole() on the server side, we use for the client getRole(). The purpose of both implementations is identical. The different naming helps to avoid confusions.
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.databind.ObjectMapper;
public class Role {
private final String API_PATH
= "/acl/" + Constraints.REST_API_VERSION + "/role";
private WebTarget target;
public RolesDO getRole(String role) throws JsonProcessingException {
Response response = target
.path(API_PATH).path(role)
.request()
.accept(MediaType.APPLICATION_JSON)
.get(Response.class);
LOGGER.log("(get) HTTP STATUS CODE: " + response.getStatus(), LogLevel.INFO);
ObjectMapper mapper = new ObjectMapper();
return mapper.readValue(response.readEntity(String.class), RolesDO.class);
}
}
Listing 5
As conclusion we have now seen the serialization and de-serialisation by using the Jackson library of JSON objects is not that difficult. In the most of the cases we just need three methods:
- serialize a Java object to a JSON String
- create a Java object from a JSON String
- de-serialize a list of objects inside a JSON String to a Java object collection
This three methods I already introduced in Listing 2 for the DAO. To prevent duplicate code we should separte those functionality in an own Java Class. This is known as the design pattern Wrapper [5] also known as Adapter. For reaching the best flexibility I implemented the JacksonJsonTools from TP-CORE as Generic.
package org.europa.together.application;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.core..JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.util.List;
public class JacksonJsonTools {
private static final long serialVersionUID = 15L;
public String serializeAsJsonObject(final T object)
throws JsonProcessingException {
try {
ObjectMapper mapper = new ObjectMapper();
return mapper.writeValueAsString(object);
} catch (JsonProcessingException ex) {
System.err.println(ex.getOriginalMessage());
}
}
public T deserializeJsonAsObject(final String json, final Class object)
throws JsonProcessingException, ClassNotFoundException {
try {
Class<?> clazz = Class.forName(object.getCanonicalName());
ObjectMapper mapper = new ObjectMapper();
return (T) mapper.readValue(json, clazz);
} catch (JsonProcessingException ex) {
System.err.println(ex.getOriginalMessage());
}
}
public List deserializeJsonAsList(final String json)
throws JsonProcessingException, ClassNotFoundException {
try {
ObjectMapper mapper = new ObjectMapper();
return mapper.readValue(json, new TypeReference<List>() {
});
} catch (com.fasterxml.jackson.core.JsonProcessingException ex) {
System.err.println(ex.getOriginalMessage());
}
}
}Listing 6
This and much more useful Implementations with a very stable API you find in my project TP-CORE for free usage.
