REST viene de “REpresentational State Transfer“, que traducido sería: “transferencia de representación de estado”, aun así, no explica del todo de que trata, pero posee la clave de lo que representa. Porque la clave de REST es que un servicio REST no posee estado (es stateless), a lo que me refiero es que, entre dos llamadas (la que sea), el servicio pierde todos los datos. Lo que lleva a que no se pueda llamar a un servicio REST y transferirle unos datos por ejemplo: (Una persona y una contraseña) y esperar que “os recuerde” en la siguiente petición. De allí proviene el nombre: El estado lo conserva el cliente y por lo tanto es el cliente quien debe pasar el estado en cada llamada. Si quiero que un servicio REST me recuerde, debo pasarle quien soy en cada llamada. Eso puede ser un usuario y una contraseña, un token o cualquier otro tipo de credenciales, pero debo pasarlas en cada llamada. Y lo mismo se usa para el resto de información.
El no poseer estado es una desventaja obvia: Asumir y pasar el estado en cada llamada es, algo minúsculo y puede ser molesto, pero la contrapartida es clara: Escalabilidad. Para cuidar un estado se tiene que poseer algún sitio (usualmente memoria) donde archivar todos los estados de todos los clientes. A más clientes, más memoria, hasta que al final se pueda llegar a no permitir entrar a más clientes, no por falta de CPU, sino de memoria. Es algo semejante a lo que sucede con la web habitual (que asimismo es stateless). Sea cual sea la tecnología con la que se desarrolle una web, seguramente que saben que pueden elaborar lo que se denomina una “sesión”. Los datos de la sesión se conservan entre peticiones y son por cada persona. El clásico ejemplo de sesión es el de un carrito de compra, entre las diferentes peticiones web, la información del carrito de compra se conserva (tengan en cuenta que existen otras opciones para implementar carritos de compra).
Por regla general, la sesión se guarda en la memoria RAM del servidor, por lo que es sencillo quedarse sin memoria si se meten muchos datos en sesión (o se tienen muchos usuarios simultáneos). Claro que, se pueden manejar distintos servidores, pero como bien saben los desarrolladores web, mover la sesión comprendida en memoria entre servidores es colectivamente improbable o realmente ineficaz, lo que penaliza el balanceo de carga, lo que a su vez rebosa en menor escalabilidad y menor aguante a fallos. Hay medios intermedios, como el guardar la sesión en base de datos, pero su bombazo en el beneficio suele ser muy creciente. También, el consejo primordial para desarrollar aplicaciones web altamente escalables es: No utilizar la sesión.
Es por eso qué, ese tiene que ser stateless el cual es la peculiaridad primordial de REST, no obstante, por supuesto no es la única. Así, cualquier servicio REST (si desea ser digno de ese nombre) tiene que no tener estado, pero no cualquier servicio sin estado es REST. Hay otros factores, pero esto va a destacar el que los ingleses llaman “uniform interface” y es lo que forma la discrepancia en un servicio web clásico (encaminado a RPC) de un servicio REST.
