Representational State Transfer, o lo que es lo mismo, REST, es cualquier interfaz basada en el estándar HTTP que se emplee tanto para obtener datos como para realizar operaciones con ellos en un gran número de formatos, ya sean JSON, XML u otros. Su sencillez es enorme en comparación con los protocolos estándar de intercambio de datos que se han usado hasta hace unos años, como XML-RPC y, sobre todo, SOAP.
Las APIs REST hacen fácil crear aplicaciones y servicios que puedan usar diferentes clientes y dispositivos. El único requisito es que entiendan HTTP, algo muy común, por ejemplo, para cualquier desarrollador web.
El experto en arquitectura de redes y uno de los principales autores de la especificación HTTP, el estadounidense Roy Fielding, fue quien, en el 2000, definió REST. Él fue quien detectó la necesidad de conseguir una arquitectura más natural y estándar para crear APIs enfocadas a dar servicios en Internet. De hecho, REST es considerado en muchas ocasiones, sobre todo, un framework orientado a la construcción de aplicaciones web.
-Sigue leyendo ¿CUÁLES SON LAS VENTAJAS DE LAS APIS REST?-
Escalabilidad de las APIs REST
Entre las particularidades de las APIs REST destaca que no es necesario guardar el estado en el servidor, por lo que toda la información debe estar disponible para la consulta por parte del cliente. Esto supone una importante ventaja, puesto que permite escalar sin que haya que preocuparse del almacenamiento de variables de sesión. Además de ello, es posible emplear tecnologías diferentes para ofrecer recursos o partes concretas de una misma API.
-¿Qué diferencias hay entre REST y SOAP?-
Niveles de calidad
Cuando se desarrolla una aplicación web, y en especial una API, a la hora de utilizar REST se trabaja con tres niveles de calidad. Leonard Richard, el gran referente de la arquitectura orientada a recursos, los estableció en un modelo que denominó ‘Richardson Maturity Model’.
- Uso correcto de URIs (Uniform Resource Identifier). Las URL (Uniform Resource Locator) son las encargadas de que se pueda identificar el recurso, además de ayudar a su acceso y permitir que podamos compartir su ubicación. Por recurso entendemos una información (página, archivo, información en una sección) a la que queremos acceder, modificar o borrar. Los URIs deben mantener una jerarquía lógica, ser independientes del formato y ser únicos para cada recurso. A la hora de nombrarlos conviene evitar verbos. Hay que recordar que los URIs no son indicados para efectuar filtrados de información de un recurso.
- Uso correcto de HTTP. Las tres claves para desarrollar APIs REST son los métodos http, los códigos de estado y la aceptación de tipos de contenido. HTTP brinda los siguientes métodos para manipular los recursos: GET (consultar y leer recursos), POST (crear recursos), PUT (editar recursos), DELETE (eliminar recursos) y PATCH (editar partes concretas de un recurso).
El header Accept es el idóneo para especificar, en HTTP, en qué formato deseamos recibir un recurso e incluso para señalar varios en orden de preferencia. La API es capaz de devolver el recurso en el primer formato disponible. Nos entregará el código de estado HTTP 406 en el caso de que no pudiera mostrar el recurso en los formatos indicados por el cliente con el header Accept. Para que el cliente pueda tener conocimiento de en qué formato se devuelve, se hará el header Content-Type.
Implementar Hypermedia. Esto es útil para conectar las aplicaciones de los clientes con las APIs mediante vínculos, lo que permite que aquellos no tengan que preocuparse por conocer antes cómo acceder a los recursos. Se trata de añadir información extra al recurso. Hypermedia ofrece otras dos grandes ventajas adicionales. Por una parte, automatiza procesos entre APIs sin que sea necesaria la interacción humana. Por otra, no hace falta que el cliente conozca las URLs de los recursos. De esta manera, si las URLs cambian, no hay que realizar mantenimientos en cada uno de los recursos.
