Header Ads Widget

Ticker

6/recent/ticker-posts

Definición de servicios web con estado y sin estado


 Como muchas industrias, el espacio API tiene su propia jerga. Muchos términos se usan con tanta frecuencia que es común suponer que la parte relacionada comprende de qué se habla. Pero para los recién llegados, estas sutiles definiciones pueden no ser tan evidentes.

Tome la diferencia entre apátridas y sin estado ; una distinción invaluable dentro del desarrollo de API y los servicios que utilizan esos sistemas. En consecuencia, en este artículo, vamos a discutir brevemente lo que realmente significan estos términos. Echemos un vistazo a lo que hace que la estadidad y la apatridia tan diferentes entre sí, y lo que esto realmente significa en términos de API.

Con estado

Para comprender la apatridia, uno debe comprender la condición de estado . Cuando hablamos de sistemas informáticos, un “ estado ” es simplemente la condición o calidad de una entidad en un instante en el tiempo, y tener estado es confiar en estos momentos en el tiempo y cambiar la salida dadas las entradas y el estado determinados.

Si no está claro, no se preocupe, es un concepto difícil de comprender, y lo es doblemente con las API. Podemos desglosar esto aún más: considere binario , un lenguaje de 1 y 0. Lo que esto representa funcionalmente es "encendido" o "apagado": un sistema binario no puede ser 1 y 0, y son mutuamente excluyentes.

Ahora, considere una situación teórica en la que le dan una hoja de papel con estas simples instrucciones - "si el número es 0, diga que no, si es 1, diga que sí" - y lo colocaron en una habitación con una pantalla binaria que cambió entre el número 0 y 1 cada cinco segundos.

Este es un sistema con estado. Su respuesta dependerá completamente de si ese reloj dice "0" o "1"; no puede responder independientemente del estado de la gran máquina. Esto es estado.

Servicios web con estado

Teniendo esto en cuenta, ¿qué hace un servicio web con estado ? Digamos que inicia sesión en un recurso y, al hacerlo, pasa su contraseña y nombre de usuario. Si el servidor web almacena estos datos de manera backend y los usa para identificarlo como un cliente constantemente conectado, el servicio tiene estado. Tenga en cuenta que este es un ejemplo muy específico que existe en otras formas, por lo que lo que parece con estado puede no necesariamente serlo; más sobre esto más adelante.

A medida que utiliza el servicio web, todo lo que hace se remite a este estado almacenado. Cuando solicita un resumen de cuenta, el servicio web pregunta dos cosas:

  • ¿Quién hace esta solicitud?
  • Utilizando la identificación almacenada para quién realiza esta solicitud, ¿cómo debería verse su página?

En un servicio web con estado como este, la respuesta formada a partir de una simple solicitud GET depende completamente del estado registrado por el servidor. Sin conocimiento de ese estado, su solicitud no se puede devolver correctamente.

Otro gran ejemplo es FTP . Cuando un usuario inicia sesión en un servidor FTP tradicional, está participando en una conexión activa con el servidor. Cada cambio en el estado del usuario, como el directorio activo, se almacena en el servidor como un estado de cliente. Cada cambio realizado en el servidor se registra como un cambio de estado y, cuando el usuario se desconecta, su estado cambia a desconectado.

Hasta aquí todo bien, ¿no? Bueno, no del todo. La programación con estado está bien en algunas aplicaciones muy limitadas, pero tiene muchos problemas . En primer lugar, cuando tiene que hacer referencia a un estado, se está abriendo a muchas sesiones y transacciones incompletas. Supongamos que realiza una llamada para presentar un dato. En un sistema con estado en el que el cliente determina el estado, ¿cuánto tiempo se supone que el sistema dejará esta conexión abierta? ¿Cómo verificamos si el cliente se ha bloqueado o se ha desconectado? ¿Cómo hacemos un seguimiento de las acciones del usuario mientras mantenemos la capacidad de documentar los cambios y revertir cuando es necesario?

Si bien es cierto que existen soluciones para todas estas preguntas, la mayoría de las veces, la statefulness solo es realmente útil cuando las funciones en sí dependen de la calidad de statefulness. La mayoría de los consumidores pueden responder al servidor de forma inteligente y dinámica y, por ello, mantener el estado del servidor independiente del consumidor como si el consumidor fuera simplemente un cliente "tonto" es un desperdicio e innecesario .

Lea también: Diseño de una verdadera máquina de estados REST

Apátrida

La respuesta a estos problemas es la apatridia . Stateless es el polo opuesto de stateful, en el que cualquier respuesta dada del servidor es independiente de cualquier tipo de estado .

Volvamos a esa sala binaria teórica. Se le da el mismo reloj binario, solo que esta vez, el papel simplemente tiene un nombre - "Jack" - y las instrucciones son para responder cuando alguien dice la contraseña "pescado". Te sientas viendo cómo el reloj cambia lentamente y cada vez que alguien dice la contraseña especial, dices el nombre "Jack".

Esto es apatridia: no es necesario ni siquiera hacer referencia al reloj, porque la información se almacena localmente de tal manera que las solicitudes son autónomas , depende solo de los datos que tiene. El hablante podría decir fácilmente la palabra secreta, decirle que cambie el nombre y luego alejarse. Luego puede regresar una hora más tarde, decir la contraseña secreta y obtener el nuevo nombre; todo está contenido en la solicitud y se maneja en dos fases distintas, con una "solicitud" y una "respuesta".

Este es un sistema sin estado. Su respuesta es independiente del "0" o del "1", y cada solicitud es independiente.

Servicios web sin estado

La apatridia es un aspecto fundamental de la Internet moderna, tanto que todos los días utiliza una variedad de servicios y aplicaciones sin estado. Cuando lee las noticias, está utilizando HTTP para conectarse sin estado, utilizando mensajes que se pueden analizar y trabajar de forma aislada entre sí y su estado.

Si tiene Twitter en su teléfono, está constantemente utilizando un servicio sin estado. Cuando el servicio solicita una lista de mensajes directos recientes utilizando la API REST de Twitter, emite la siguiente solicitud:

GET https://api.twitter.com/1.1/direct_messages.json?since_id=240136858829479935&count=1

La respuesta que obtendrá es completamente independiente de cualquier almacenamiento de estado del servidor, y todo se almacena en el lado del cliente en forma de caché.

Echemos un vistazo a otro ejemplo. En el siguiente ejemplo, estamos invocando un comando POST, creando un registro en HypotheticalService:



POST http://HypotheticalService/Entity
Host: HypotheticalService
Content-Type: text/xml; charset=utf-8
Content-Length: 123

1
This is an example


En este ejemplo, estamos creando una entrada, pero esta entrada no depende de ningún asunto de estado . Tenga en cuenta que este es un caso de uso simple, ya que no pasa ningún dato de autorización / autenticación, y la emisión POST en sí contiene solo datos muy básicos.

Incluso con todo esto en mente, puede ver claramente que hacer una emisión POST sin estado significa que no tiene que esperar la sincronización del servidor para asegurarse de que el proceso se haya completado correctamente, como lo haría con FTP u otros servicios con estado. . Recibe una confirmación, pero esta confirmación es simplemente una respuesta afirmativa, en lugar de un estado compartido mutuo.

Como nota rápida, debe decirse que REST está diseñado específicamente para ser funcionalmente apátrida . Todo el concepto de Transferencia de estado representacional (del que REST recibe su nombre) depende de la idea de pasar todos los datos para manejar la solicitud de tal manera que se emparejen los datos dentro de la solicitud misma. Por lo tanto, REST debe considerarse apátrida (y, de hecho, esa es una de las principales consideraciones sobre si algo es RESTful o no, según la disertación original de Roy Fielding que detalla el concepto ).

Consulte también: Instancias comunes de API no RESTful y Lo que realmente importa

Humo y espejos

Sin embargo, debemos tener algo de cuidado cuando hablamos de servicios web como ejemplos de estado o sin estado, porque lo que parece estar en una categoría puede no serlo en realidad. Esto se debe en gran parte a que los servicios sin estado han logrado reflejar gran parte del comportamiento de los servicios con estado sin cruzar técnicamente la línea.

La apatridia se trata, al igual que nuestro ejemplo anterior, de un estado y una referencia autónomos en lugar de depender de un marco de referencia externo. La diferencia entre esto y la statefulness es realmente donde se almacena el estado. Cuando navegamos por Internet o accedemos a nuestro correo, estamos generando un estado, y ese estado tiene que ir a alguna parte.

Cuando el servidor almacena el estado, genera una sesión. Esta es la computación con estado . Cuando el cliente almacena el estado, genera algún tipo de datos que se utilizarán para varios sistemas; aunque técnicamente tiene "estado" en el sentido de que hace referencia a un estado, el estado lo almacena el cliente, por lo que nos referimos a él como sin estado. .

Esto parece confuso, pero en realidad es la mejor manera de evitar las limitaciones de la apatridia. En un sistema puramente sin estado, esencialmente estamos interactuando con un sistema limitado : cuando solicitamos un producto en línea, eso sería todo para nosotros, no almacenaría nuestra dirección, nuestros métodos de pago, ni siquiera un registro de nuestro pedido. , simplemente procesaría nuestro pago y, en lo que respecta al servidor, dejaríamos de serlo.

Obviamente, ese no es el mejor de los casos, por lo que hicimos algunas concesiones. En la cookie del cliente, almacenamos algunos datos de autenticación básicos. En el lado del servidor, creamos algunos datos temporales del cliente o los almacenamos en una base de datos y los referenciamos a un dato externo. Cuando volvemos a realizar otro pago, es nuestra cookie la que establece el estado, no la sesión inexistente.

¿Qué tienen de malo las sesiones?

En cuanto a servicios web, el paradigma comúnmente aceptado es evitar las sesiones a toda costa. Si bien esto ciertamente no se aplica a todos los casos de uso, el uso de sesiones como método para comunicar el estado es generalmente algo que debe evitar.

Para empezar, las sesiones agregan una gran cantidad de complejidad con muy poco valor agregado. Las sesiones hacen que sea más difícil replicar y corregir errores. Las sesiones no se pueden "marcar" realmente, ya que todo se almacena en el lado del servidor. Todos estos son problemas importantes, pero palidecen en comparación con el simple hecho de que las sesiones no son escalables .

Gregor Riegler de BeABetterDeveloper dio una maravillosa explicación de por qué esto está en su pieza "Sessions, a Pitfall" :

Supongamos que eres un jugador de ajedrez profesional y te gustaría jugar con varias personas al mismo tiempo. Si intenta recordar cada juego y su estrategia, alcanzará su capacidad bastante rápido. Ahora imagina que no recuerdas nada de esos juegos y que simplemente relees el tablero de ajedrez en cada movimiento. Literalmente, podrías jugar con 1.000.000 de personas al mismo tiempo, y no supondría ninguna diferencia para ti.

Ahora dibuje una analogía con su servidor. Si su aplicación recibe mucha carga, es posible que deba distribuirla a diferentes servidores. Si estaba utilizando sesiones, de repente tendría que replicar todas las sesiones en todos los servidores. El sistema se volvería aún más complejo y propenso a errores.

En pocas palabras, las sesiones no hacen lo que están diseñadas para hacer sin introducir una tonelada de sobrecarga , y su funcionalidad se puede replicar fácilmente mediante cookies, almacenamiento en caché de clientes y otras soluciones similares. Por supuesto, existen situaciones en las que las sesiones tienen sentido, especialmente cuando los servidores querían almacenar el estado sin tener ni siquiera el mínimo potencial de datos de tiempo de ejecución del cliente modificados.

Por ejemplo, FTP tiene estado por una muy buena razón, ya que replica los cambios tanto en el lado del cliente como en el lado del servidor al tiempo que brinda mayor seguridad debido a la naturaleza del acceso solicitado. Esto es factible porque una sola persona necesita acceder a un solo servidor para una sola transferencia de datos establecida, incluso si la transferencia involucra múltiples carpetas, archivos y directorios.

Ese no es el caso con algo como un Dropbox compartido, en el que las sesiones con estado causarían la complejidad adicional sin agregar valor. En este caso, los apátridas serían una opción mucho mejor.

Conclusión

Esperamos que esto haya aclarado la diferencia entre las arquitecturas con estado y sin estado cuando se trata de API. La comprensión de este concepto simple es la base sobre la que se basan la mayoría de las arquitecturas y diseños; conceptos tan elevados como el diseño RESTful se basan en estas ideas, por lo que tener un marco conceptual sólido es extremadamente importante.

Publicar un comentario

0 Comentarios