Servicios web RESTful: apatridia

Según la arquitectura REST, un servicio web RESTful no debe mantener un estado de cliente en el servidor. Esta restricción se llama apatridia. Es responsabilidad del cliente pasar su contexto al servidor y luego el servidor puede almacenar este contexto para procesar la solicitud adicional del cliente. Por ejemplo, la sesión mantenida por el servidor se identifica mediante el identificador de sesión pasado por el cliente.

Los servicios web RESTful deben cumplir con esta restricción. Hemos visto esto en el capítulo Servicios web RESTful - Métodos , que los métodos del servicio web no almacenan ninguna información del cliente desde el que se invocan.

Consider the following URL −

https: // localhost: 8080 / UserManagement / rest / UserService / users / 1

Si presiona la URL anterior usando su navegador o usando un cliente basado en java o usando Postman, el resultado siempre será el XML de usuario cuyo Id es 1 porque el servidor no almacena ninguna información sobre el cliente.

<user> 
   <id>1</id> 
   <name>mahesh</name> 
   <profession>1</profession> 
</user>

Ventajas de la apatridia

Los siguientes son los beneficios de la apatridia en los servicios web RESTful:

  • Los servicios web pueden tratar cada solicitud de método de forma independiente.

  • Los servicios web no necesitan mantener las interacciones previas del cliente. Simplifica el diseño de la aplicación.

  • Como HTTP es en sí mismo un protocolo de ausencia de estado, los servicios web RESTful funcionan a la perfección con los protocolos HTTP.

Desventajas de la apatridia

Las siguientes son las desventajas de la apatridia en los servicios web RESTful:

  • Los servicios web necesitan obtener información adicional en cada solicitud y luego interpretar para obtener el estado del cliente en caso de que se deban atender las interacciones del cliente.