Transferencia de Estado Representacional para niños
La Transferencia de Estado Representacional (conocida como REST, por sus siglas en inglés) es un estilo de diseño para crear sistemas de software que se comunican a través de una red, como la World Wide Web. Imagina que es como un conjunto de reglas o un "estilo" que ayuda a que diferentes computadoras se entiendan y compartan información de manera eficiente.
El término REST fue creado en el año 2000 por Roy Fielding en su tesis doctoral. Roy Fielding fue una persona muy importante en el desarrollo del protocolo HTTP, que es la base de cómo funciona la web. Desde entonces, REST se ha vuelto muy popular entre los programadores.
Contenido
¿Cómo surgió REST?
La World Wide Web, o simplemente la web, comenzó a ser usada por muchas personas entre 1993 y 1994. En ese momento, no había una forma clara de describir cómo funcionaba la arquitectura de la web. Había mucha presión para crear estándares que ayudaran a las computadoras a comunicarse mejor.
Roy Fielding participó en la creación de los estándares principales de la web, como los URI (direcciones web) y el HTTP. Durante seis años, desarrolló el estilo arquitectónico REST. Lo usó para mejorar los protocolos de la web y para identificar problemas en su diseño. Finalmente, Fielding definió REST en su tesis doctoral del año 2000.
¿Qué es REST en la práctica?
Aunque REST se refiere a un conjunto de principios de diseño, hoy en día se usa de forma más amplia para describir cualquier forma en que los sistemas se conectan usando directamente HTTP. Esto significa que usan los comandos de HTTP para pedir o enviar datos, sin necesidad de otros protocolos más complejos. Los datos pueden estar en formatos como XML o JSON.
REST se basa en algunas ideas clave que han hecho que la web sea tan grande y funcione tan bien:
Un protocolo cliente/servidor sin estado
Imagina que cada vez que pides algo en una tienda, el vendedor no recuerda nada de tus visitas anteriores. Cada vez que le pides algo, tienes que darle toda la información de nuevo. Así funciona un protocolo "sin estado": cada mensaje HTTP que se envía contiene toda la información necesaria. Esto significa que ni tu computadora (el cliente) ni el servidor necesitan recordar lo que pasó en mensajes anteriores.
Operaciones bien definidas
HTTP tiene un pequeño grupo de operaciones o "verbos" que se usan para interactuar con la información. Los más importantes son:
- POST: Para enviar nueva información (como crear una publicación en una red social).
- GET: Para obtener información (como ver una página web).
- PUT: Para actualizar información existente (como cambiar tu perfil).
- DELETE: Para borrar información.
Estas operaciones son como las acciones básicas que puedes hacer con los datos.
Una forma universal de identificar información
En un sistema REST, cada pieza de información, llamada "recurso", tiene una dirección única. Esta dirección se llama URI (como una URL de una página web). Es como la dirección de una casa: cada casa tiene una dirección única para que puedas encontrarla.
Uso de hipermedios
Esto significa que la información que recibes (por ejemplo, una página HTML o un archivo XML) contiene enlaces a otras partes de la aplicación. Es como cuando navegas por una página web y haces clic en un enlace para ir a otra página. En REST, puedes moverte entre diferentes recursos simplemente siguiendo estos enlaces, sin necesidad de buscar en otros lugares.
¿Qué son los recursos en REST?
Un "recurso" es una pieza de información que existe en el sistema. Puede ser una foto, un texto, un usuario, o cualquier dato. Cada recurso tiene un identificador único (su URI). Para trabajar con estos recursos, las computadoras (clientes y servidores) se comunican usando HTTP e intercambian "representaciones" de esos recursos. Una representación es el formato en que se envía la información, como un archivo HTML o XML.
Cuando tu computadora pide un recurso, no necesita saber si hay otros sistemas intermedios como cachés o cortafuegos. Solo necesita saber la dirección del recurso y qué acción quiere realizar. Sin embargo, tu computadora sí debe entender el formato de la información que recibe.
REST vs. RPC: ¿Cuál es la diferencia?
Imagina que quieres interactuar con una base de datos de usuarios y ubicaciones.
En un sistema basado en RPC (llamada de procedimiento remoto), te enfocarías en las "operaciones" que puedes hacer. Por ejemplo, tendrías comandos como:
- `obtenerUsuario()`
- `añadirUsuario()`
- `eliminarUsuario()`
- `actualizarUsuario()`
- `obtenerUbicacion()`
- `añadirUbicacion()`
- `eliminarUbicacion()`
- `actualizarUbicacion()`
- `listarUsuarios()`
- `listarUbicaciones()`
- `buscarUbicacion()`
- `buscarUsuario()`
En un sistema REST, el enfoque está en los "recursos" o "sustantivos". Definirías tipos de recursos como:
- `Usuario`
- `Ubicación`
Cada recurso tendría su propia dirección única, por ejemplo: `http://www.ejemplo.org/ubicaciones/us/ny/ciudad_de_nueva_york`. Para interactuar con estos recursos, usarías las operaciones estándar de HTTP:
- Para obtener la información de un usuario, usarías GET en la dirección de ese usuario.
- Para actualizar la ubicación de un usuario, primero obtendrías su información con GET, la modificarías, y luego la enviarías de vuelta con PUT.
Una ventaja de REST es que cada recurso tiene su propia dirección, lo que facilita guardarlos, copiarlos o compartirlos. Para buscar o listar recursos, REST trata los resultados de la búsqueda como otro tipo de "recurso". Por ejemplo, pedir `http://www.ejemplo.org/ubicaciones/us/ny/` podría devolver una lista de todas las ubicaciones en Nueva York.
Principios clave de REST
Roy Fielding definió REST con varios principios importantes:
- Arquitectura cliente-servidor: Esto significa que hay una separación clara entre la parte que pide la información (el cliente, como tu navegador) y la parte que la proporciona (el servidor). Esto hace que el sistema sea más flexible y fácil de cambiar.
- Ausencia de estado: Como mencionamos, el servidor no guarda información sobre las interacciones anteriores con un cliente. Cada solicitud debe contener toda la información necesaria para ser procesada. Esto ayuda a que el sistema sea más escalable y robusto.
- Uso de la caché: Los sistemas REST pueden usar "cachés" para guardar copias de las respuestas. Si una respuesta se guarda en la caché, la próxima vez que se pida la misma información, se puede entregar más rápido sin tener que ir hasta el servidor original. Esto ahorra tiempo y recursos.
- Sistema por capas: Un cliente solo necesita saber con qué capa del sistema está hablando. No necesita preocuparse por los detalles internos, como qué tipo de base de datos se usa o si hay otros servidores intermedios. Esto simplifica el diseño y el mantenimiento.
- Interfaz uniforme: Este es uno de los principios más importantes y tiene varias partes:
- Identificación de recursos en las peticiones: Cada solicitud identifica un recurso específico. El recurso es una idea, y su "representación" es cómo se ve (por ejemplo, en HTML o XML). El cliente y el servidor pueden acordar el formato de la representación.
- Manipulación de recursos a través de representaciones: Cuando un cliente tiene la representación de un recurso, tiene suficiente información para modificarlo o eliminarlo. Esto significa que el cliente puede "predecir" lo que sucederá al realizar una operación.
- Mensajes autodescriptivos: Cada mensaje que se envía debe contener toda la información que el cliente necesita para entenderlo. No debería ser necesario consultar una documentación externa para saber qué significa un mensaje.
- Hipermedia como motor del estado de la aplicación (HATEOAS): Una vez que un cliente se conecta a la aplicación, debería poder descubrir todos los recursos disponibles simplemente siguiendo los enlaces que el servidor le proporciona. Esto significa que el cliente no necesita tener direcciones "escritas a mano" en su código, sino que las descubre dinámicamente.
Niveles de madurez de una API REST
No todas las implementaciones de REST son iguales. El "modelo de madurez de Richardson" describe cómo una API (una forma en que los programas se comunican) puede volverse más "RESTful" (es decir, seguir más los principios de REST) a lo largo de cuatro niveles:
- Nivel 0: Los servicios tienen una sola dirección para todas las operaciones. No se considera una API RESTful.
- Nivel 1: Introduce recursos, permitiendo peticiones a direcciones individuales para acciones separadas. Los recursos son más específicos. Todavía no es completamente RESTful.
- Nivel 2: El sistema empieza a usar los verbos HTTP (GET, POST, PUT, DELETE). Esto permite una mayor especialización, por ejemplo, una dirección para obtener datos (GET) y otra para modificarlos (POST).
- Nivel 3: Introduce la representación de hipermedia (HATEOAS). Los mensajes de respuesta incluyen enlaces a otros recursos relacionados, permitiendo al cliente descubrir nuevas acciones y recursos dinámicamente. Por ejemplo, al pedir información sobre un hotel, la respuesta podría incluir enlaces para reservar habitaciones específicas.
REST vs. SOAP
A veces se compara REST con otro protocolo llamado SOAP. Aquí te explicamos las diferencias principales:
- Enfoque: REST se centra en los datos (recursos), mientras que SOAP se enfoca en los servicios que operan con esos datos.
- Flexibilidad vs. Estandarización: REST es un "estilo" de diseño, lo que lo hace más flexible. SOAP es un "protocolo" más estricto y estandarizado.
- Formato de mensajes: Los clientes REST suelen enviar y recibir información en HTML o XML, y a menudo usan JSON por ser más ligero. SOAP casi siempre usa XML, que es más "verboso" (usa más palabras) y puede requerir más ancho de banda.
- Pruebas: Puedes probar un servicio REST directamente desde un navegador web. Para probar SOAP, necesitas herramientas especiales.
- Operaciones comunes: REST se basa en la idea de que la operación más frecuente es la "lectura" (GET). SOAP se construye más con peticiones POST.
Ventajas y desventajas de REST
Como cualquier diseño, REST tiene sus puntos fuertes y débiles:
Ventajas:
- Es más sencillo de implementar en muchos casos, tanto para el cliente como para el servidor.
- Muchos marcos de trabajo (frameworks) de programación lo ofrecen por defecto.
- Hay un gran consenso entre los programadores sobre cómo esperar que funcionen las APIs REST.
Desventajas:
- La visibilidad de las direcciones web públicas puede ser un problema de seguridad si no se maneja bien.
- Puede haber limitaciones técnicas en la longitud de los parámetros en las direcciones, aunque esto se puede solucionar con peticiones POST.
- SOAP, al ser más estandarizado, puede ahorrar decisiones sobre detalles de implementación y ofrecer operaciones de forma más transparente.
Ejemplos de uso de REST
REST se usa en muchísimas aplicaciones en la web. Prácticamente cualquier cosa a la que accedes con una petición HTTP GET tiene algo de REST. Aquí algunos ejemplos más específicos:
- La mayoría de los blogs usan REST, ya que implican descargar archivos XML (como RSS o Atom) que contienen listas de enlaces a otros contenidos.
- Grandes empresas como Amazon.com, Facebook, Twitter y MercadoLibre ofrecen sus APIs para desarrolladores basadas en REST.
- Muchos sitios web y servicios usan REST para permitir que diferentes aplicaciones se conecten y compartan información de manera eficiente.
Es importante saber que muchas de estas implementaciones no siguen al pie de la letra todas las reglas de REST, pero sí se inspiran en sus ideas principales, especialmente en la "interfaz uniforme".
Galería de imágenes
-
Roy Fielding charlando durante OSCON 2008
Véase también
En inglés: REST Facts for Kids
