REST es un acrónimo de REpresentational State Transfer y un estilo arquitectónico para sistemas hipermedia distribuidos.
Los seis principios rectores o Restricciones de REST son:
- Interfaz uniforme
- Servidor de cliente
- Apátrida
- almacenable en caché
- arquitectura en capas
- Código bajo demanda (opcional).
Discutiremos la restricción sin estado de REST en profundidad en este artículo.
NOTA: Según la arquitectura REST {Representational «State» Transfer}, el servidor no almacena ninguna información sobre el lado del cliente en el lado del servidor.
Cada solicitud del cliente al servidor debe contener toda la información necesaria para procesar esa solicitud y esa información no se puede almacenar en el lado del servidor para futuras referencias. Esta restricción se llama apatridia.
El cliente es responsable de almacenar y manejar la información relacionada con la sesión por su cuenta. Si se requiere alguna información de la solicitud anterior, el cliente la compartirá en la solicitud actual.
“ La apatridia significa que cada solicitud HTTP ocurre en completo aislamiento”.
El estado de la aplicación es la información almacenada en el lado del servidor para identificar las requests entrantes y las interacciones anteriores, la apatridia REST significa estar libre del estado de la aplicación.
Ventajas de la apatridia REST:
- Fácilmente escalable: como no hay necesidad de almacenar información, cualquier servidor puede manejar cualquier solicitud de cliente. Por lo tanto, se pueden procesar muchas requests simultáneas mediante la implementación de la API en varios servidores.
- Complejidad reducida: como no se necesita sincronización de estado, se reduce la complejidad.
- Rendimiento mejorado: el servidor no necesita realizar un seguimiento de las requests de los clientes, lo que aumenta el rendimiento.
Desventajas de la apatridia REST:
- Aumento del tamaño de la solicitud: el tamaño de la solicitud se vuelve muy grande muchas veces, ya que contiene toda la información sobre la solicitud y las transacciones anteriores.
EJEMPLO de apatridia:
Supongamos que tenemos una API en la que queremos iniciar sesión y pedir algunos productos, la API implementada en muchos servidores puede atender muchas requests, incluso desde la misma cuenta sin almacenar los detalles de autenticación o el estado del token proporcionado.
Cada vez que el cliente realiza una solicitud, enviará los detalles de autenticación, así como la otra información requerida, y esa solicitud se puede procesar fácilmente en el lado del servidor, ya que incluye toda la información necesaria para cumplir con la solicitud.
Publicación traducida automáticamente
Artículo escrito por mustufakhan y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA