¿qué es una API REST?

El diseño de API REST o RESTful (transferencia de Estado de representación) está diseñado para aprovechar los protocolos existentes. Si bien REST se puede usar sobre casi cualquier protocolo, generalmente aprovecha HTTP cuando se usa para API Web. Esto significa que los desarrolladores no necesitan instalar bibliotecas o software adicional para aprovechar un diseño de API REST. El diseño de REST API fue definido por el Dr. Roy Fielding en su disertación de doctorado de 2000. Es notable por su increíble capa de flexibilidad., Dado que los datos no están vinculados a métodos y recursos, REST tiene la capacidad de manejar múltiples tipos de llamadas, devolver diferentes formatos de datos e incluso cambiar estructuralmente con la implementación correcta de hypermedia.

esta libertad y flexibilidad inherentes al diseño de la API REST le permiten crear una API que satisfaga sus necesidades y, al mismo tiempo, satisfaga las necesidades de clientes muy diversos. A diferencia de SOAP, REST no está limitado a XML, sino que puede devolver XML, JSON, YAML o cualquier otro formato dependiendo de lo que solicite el cliente., Y a diferencia de RPC, los usuarios no están obligados a conocer los nombres de los procedimientos o parámetros específicos en un orden específico.

sin embargo, hay inconvenientes en el diseño de la API REST. Puede perder la capacidad de mantener el estado en reposo, como dentro de las sesiones, y puede ser más difícil de usar para los desarrolladores más nuevos. También es importante comprender qué hace que una API REST sea RESTful y por qué existen estas restricciones antes de crear su API. Después de todo, si no entiendes por qué algo está diseñado de la manera en que está, puedes obstaculizar tus esfuerzos sin siquiera darte cuenta.,

comprensión del diseño de API REST

aunque la mayoría de las API afirman ser RESTful, no cumplen con los requisitos y restricciones establecidos por el Dr. Fielding. Hay seis restricciones clave para el diseño de la API REST a tener en cuenta al decidir si este es el tipo de API adecuado para su proyecto.

Cliente-Servidor

La restricción cliente-servidor funciona en el concepto de que el cliente y el servidor deben estar separados el uno del otro y permitir que evolucionen individual e independientemente., En otras palabras, debería poder realizar cambios en mi aplicación móvil sin afectar la estructura de datos o el diseño de la base de datos en el servidor. Al mismo tiempo, debería poder modificar la base de datos o hacer cambios en mi aplicación de servidor sin afectar al cliente móvil. Esto crea una separación de preocupaciones, permitiendo que cada aplicación crezca y se amplíe independientemente de la otra y permitiendo que su organización crezca de manera rápida y eficiente.,

sin estado

las API REST son sin estado, lo que significa que las llamadas se pueden realizar independientemente unas de otras, y cada llamada contiene todos los datos necesarios para completarse correctamente. Una API REST no debe depender de los datos almacenados en el servidor o las sesiones para determinar qué hacer con una llamada, sino que debe depender únicamente de los datos que se proporcionan en esa llamada en sí. La información de identificación no se almacena en el servidor al realizar llamadas. En su lugar, cada llamada tiene los datos necesarios en sí misma, como la clave API, el token de acceso, el ID de usuario, etc., Esto también ayuda a aumentar la confiabilidad de la API al tener todos los datos necesarios para realizar la llamada, en lugar de depender de una serie de llamadas con estado de servidor para crear un objeto, lo que puede resultar en errores parciales. En su lugar, para reducir los requisitos de memoria y mantener su aplicación lo más escalable posible, una API RESTful requiere que cualquier estado se almacene en el cliente, no en el servidor.

Cache

debido a que una API sin estado puede aumentar la sobrecarga de solicitudes al manejar grandes cargas de llamadas entrantes y salientes, se debe diseñar una API REST para fomentar el almacenamiento de datos en caché., Esto significa que cuando los datos se pueden almacenar en caché, la respuesta debe indicar que los datos se pueden almacenar hasta un cierto tiempo (caduca-at), o en los casos en que los datos deben ser en tiempo real, que la respuesta no debe ser almacenada en caché por el cliente. Al habilitar esta restricción crítica, no solo reducirá en gran medida el número de interacciones con su API, reduciendo el uso del servidor interno, sino que también proporcionará a los usuarios de su API las herramientas necesarias para proporcionar las aplicaciones más rápidas y eficientes posibles. Tenga en cuenta que el almacenamiento en caché se realiza en el lado del cliente., Si bien es posible que pueda almacenar en caché algunos datos dentro de su arquitectura para realizar el rendimiento general, la intención es instruir al cliente sobre cómo debe proceder y si el cliente puede almacenar los datos temporalmente o no.

interfaz uniforme

la clave para desacoplar el cliente del servidor es tener una interfaz uniforme que permita la evolución independiente de la aplicación sin tener los servicios, modelos o acciones de la aplicación estrechamente acoplados a la propia capa de API., La interfaz uniforme permite al cliente hablar con el servidor en un solo idioma, independientemente del backend arquitectónico de cualquiera de ellos. Esta interfaz debe proporcionar un medio invariable y estandarizado de comunicación entre el cliente y el servidor, como el uso de HTTP con recursos URI, CRUD (Create, Read, Update, Delete) y JSON.

sistema en capas

como su nombre indica, un sistema en capas es un sistema compuesto de capas, con cada capa teniendo una funcionalidad y responsabilidad específicas., Si pensamos en un marco de controlador de vista de modelo, cada capa tiene sus propias responsabilidades, con los modelos que comprenden cómo se deben formar los datos, el controlador se centra en las acciones entrantes y la vista se centra en la salida. Cada capa está separada, pero también interactúa con la otra. En el diseño de API REST, el mismo principio es válido, con diferentes capas de la arquitectura trabajando juntas para construir una jerarquía que ayuda a crear una aplicación más escalable y modular.,

un sistema en capas también le permite encapsular sistemas heredados y mover la funcionalidad a la que se accede con menos frecuencia a un intermediario compartido, al tiempo que protege de ellos los componentes más modernos y de uso común. Además, el sistema de capas le da la libertad de mover sistemas Dentro y fuera de su arquitectura a medida que las tecnologías y los servicios evolucionan, aumentando la flexibilidad y la longevidad, siempre y cuando Mantenga los diferentes módulos lo más libremente posible acoplados., Hay beneficios de seguridad sustanciales de tener un sistema por capas, ya que le permite detener los ataques en la capa de proxy, o dentro de otras capas, evitando que lleguen a su arquitectura de servidor real. Al utilizar un sistema en capas con un proxy o crear un único punto de acceso, puede mantener los aspectos críticos y más vulnerables de su arquitectura detrás de un firewall, evitando la interacción directa con ellos por parte del cliente., Tenga en cuenta que la seguridad no se basa en una única solución «detener todo», sino en tener varias capas con el entendimiento de que ciertas comprobaciones de seguridad pueden fallar o ser omitidas. Como tal, cuanta más seguridad pueda implementar en su sistema, más probabilidades tendrá de evitar ataques dañinos.

Code on Demand

quizás la menos conocida de las seis restricciones, y la única restricción opcional, Code on Demand permite que el código o los applets se transmitan a través de la API para su uso dentro de la aplicación., En esencia, crea una aplicación inteligente que ya no depende únicamente de su propia estructura de código. Sin embargo, tal vez debido a que se adelanta a su tiempo, Code on Demand ha tenido problemas para su adopción, ya que las API Web se consumen en varios idiomas y la transmisión de código plantea preguntas y preocupaciones de seguridad. (Por ejemplo, el directorio tendría que ser escribible, y el cortafuegos tendría que dejar pasar lo que normalmente puede ser contenido restringido.)

juntas, estas restricciones conforman la teoría de la transferencia de Estado representacional, o resto., Al mirar hacia atrás, puede ver cómo cada restricción sucesiva se construye sobre la anterior, creando finalmente una interfaz de programa de aplicación bastante compleja, pero potente y flexible. Pero lo más importante, estas restricciones conforman un diseño que funciona de manera similar a cómo accedemos a las páginas en nuestros navegadores en la World Wide Web. Crea una API que no está dictada por su arquitectura, sino por las representaciones que devuelve, y una API que, aunque arquitectónicamente sin estado, se basa en la representación para dictar el estado de la aplicación.,

para obtener más información sobre el diseño de la API REST, consulte el eBook Rest imperturbable: una guía para diseñar la API perfecta.