Solución:
Para actualizar esto, el consejo sobre Serializable ha cambiado, la recomendación actualmente parece ser No usar Serializable para nada.
El uso de la API de serialización de Java significa que necesita algo en Java en el otro lado del cable para deserializar los objetos, por lo que debe controlar el código que deserializa así como el código que serializa.
Por lo general, esto no es relevante para las aplicaciones REST, consumir la respuesta de la aplicación es asunto del código de otra persona, generalmente fuera de su organización. Al crear una aplicación REST, es normal tratar de evitar imponer limitaciones sobre lo que la consume, eligiendo un formato que sea más independiente de la tecnología y esté más disponible.
Algunas razones para tener un objeto implementado java.io.Serializable sería:
-
para que puedas ponerlo en una HttpSession
-
para que pueda pasarlo a través de una red entre partes de una aplicación distribuida
-
para que pueda guardarlo en el sistema de archivos y restaurarlo más tarde (por ejemplo, podría hacer que el contenido de una cola sea serializable y guardar el contenido de la cola cuando la aplicación se apague, leyendo desde la ubicación de guardado cuando la aplicación comience a restaurar el cola a su estado en el apagado).
En todos estos casos, se serializa para poder guardar algo en un sistema de archivos o enviarlo a través de una red.
Hay muchas formas de serializar un objeto. La serialización de objetos de Java es solo uno de ellos. De la documentación oficial:
Serializar un objeto significa convertir su estado en un flujo de bytes.
Las API REST generalmente envían y reciben JSON o XML. En ese caso, serializar un objeto significa convertir su estado en un String.
No existe una conexión directa entre “enviar un objeto por cable” e implementar Serializable. Las tecnologías que utiliza dictan si o no Serializable tiene que ser implementado.
Los ejemplos específicos que ha mencionado no transfieren objetos a través del cable. De los enlaces de ejemplo, veo que los métodos del controlador devuelven un objeto de dominio con ResponseBody anotación. Solo porque el tipo de retorno del método es el objeto de dominio, no es necesario que todo el objeto se envíe al cliente. Uno de los métodos del controlador en el marco Spring mvc intercepta internamente la invocación y determina que el tipo de retorno del método no se traduce en directo ModelAndView objeto. RequestResponseBoodyMethodProcessor que maneja el valor de retorno de dichos métodos anotados y usa uno de los convertidores de mensajes para escribir el objeto de retorno en el cuerpo de respuesta http. En el caso de que el convertidor de mensajes utilizado sea MappingJackson2HttpMessageConverter. Entonces, si va a seguir el mismo estilo de codificación, no es necesario que implemente Serializable para sus objetos de dominio.
Eche un vistazo a este enlace para los convertidores de mensajes Http proporcionados por defecto desde Spring. La lista es bastante extensa, pero no exhaustiva y, si surgen requisitos, también puede implementar su propio convertidor de mensajes personalizado para el usuario.