Spring MVC - should my domain classes implement Serializable for over-the-wire transfer?

Question

I'm trying to learn Spring Boot by implementing a simple REST API.

My understanding was that if I need to transfer an object over the wire, that object should implement Serializable.

In many examples on the net though, including official ones, domain classes that need to be transferred from server to client (or vice-versa) do not to implement Serializable.

For instance: https://spring.io/guides/gs/rest-service/

But in some cases, they do:

For instance: https://github.com/szerhusenBC/jwt-spring-security-demo/blob/master/src/main/java/org/zerhusen/security/JwtAuthenticationRequest.java

Is there a general rule of thumb on when to implement Serializable?

Solution 1

To update this, advice about Serializable has changed, the recommendation currently seems to be Don’t use Serializable for anything.

Using the Java serialization API means you need something in Java on the other side of the wire to deserialize the objects, so you have to control the code that deserializes as well as the code that serializes.

This typically isn't relevant for REST applications, consuming the application response is the business of someone else's code, usually outside your organization. When building a REST application it's normal to try to avoid imposing limitations on what is consuming it, picking a format that is more technology-agnostic and broadly available.

Some reasons for having an object implement java.io.Serializable would be:

• so you can put it in an HttpSession

• so you can pass it across a network between parts of a distributed application

• so you can save it to the file system and restore it later (for instance, you could make the contents of a queue serializable and have the queue contents saved when the application shuts down, reading from the save location when the application starts to restore the queue to its state on shutdown).

In all these cases, you serialize so you can save something to a filesystem or send it across a network.

Solution 2

There are many ways to serialize an object. Java's object serialization is just one of them. From the official documentation:

To serialize an object means to convert its state to a byte stream

REST APIs usually send and receive JSON or XML. In that case serializing an object means converting its state to a String.

There is no direct connection between "sending an object over the wire" and implementing Serializable. The technologies you use dictate whether or not Serializable has to be implemented.

Solution 3

The specific examples you have mentioned do not transfer objects over the wire. From the example links I see that the controller methods return a domain object with ResponseBody annotation. Just because the return type of the method is the domain object it is not necessary that the whole object is being sent to the client. One of the handler method in Spring mvc framework internally intercepts the invocation and determines that the method return type does not translate to direct ModelAndView object. RequestResponseBoodyMethodProcessor which handles the return value of such annotated methods and uses one of the message converters to write the return object to the http response body. In the case the message converter used would be MappingJackson2HttpMessageConverter. So if are to follow the same coding style you are not required to implement Serializable for your domain objects.

Have a look at this link for the Http message converters provided by default from spring. The list is quiet extensive however not exhaustive and if requirements arise you can implement your own custom message converter to user as-well.

Solution 4

that's a good question when to implement Serializable interface.

these links can provides some useful contents:

Serializing java.io.Serializable instance into JSON with Spring and Jackson JSON

When and why JPA entities should implement Serializable interface?

I sometimes wonder about this,and I think

Because Java is a open source language,and more libraries providered by third party.for tells who will serialize and deserialize the object,the java offical declare a constract interface,makes transfer easy and safety throught different library.

It's just a constract,most third-party libraries can serialize/deserialize when checking implement this constract.and jackson's jar library is not use it.

So you can deem if you use serialize/deserialize object data in your own system,and simple process,likes just serialize and response it(jackson in spring MVC),you needn't to implements it. but if you used in other jar library,likes saving in HttpSession,or other third-party componens/library,you should(or have to) implement Serializable,otherwise the libraries will throw a exception to tell you the constract interfaced which it knows is not provide.

But they said it's a good habit and best properties that to implement the Serializable when serialize a custom class. :)

View more solutions