¿Qué es la API REST?

Primero, definido en 2000 por el científico informático Dr. Roy Fielding en su tesis doctoral, REST proporciona a los desarrolladores un nivel relativamente alto de flexibilidad, constancia, escalabilidad y eficiencia. Las API REST proporcionan una forma ligera de crear API web y se utilizan comúnmente para facilitar el intercambio de datos entre aplicaciones, servicios web y bases de datos, y para conectar componentes en arquitecturas de microservicios.

En el nivel más básico, una API es un mecanismo que permite que una aplicación o servicio acceda a un recurso dentro de otra aplicación, servicio o base de datos. La aplicación o servicio que accede a los recursos es el cliente y la aplicación o servicio que contiene el recurso es el servidor.

Algunas API, como SOAP o XML-RPC, imponen un marco estricto a los desarrolladores. Pero los desarrolladores pueden desarrollar API REST utilizando prácticamente cualquier lenguaje de programación y admitir varios formatos de datos. El único requisito es que se alineen con los siguientes seis principios de diseño REST, también conocidos como restricciones arquitectónicas.

Todas las solicitudes de API para el mismo recurso deben tener el mismo aspecto, independientemente de su procedencia. La API REST debe garantizar que el mismo dato, como el nombre o la dirección de correo electrónico de un usuario, pertenezca a un solo identificador de recursos uniforme (URI). Los recursos no deben ser demasiado grandes, pero deben contener toda la información que el cliente pueda necesitar.

En el diseño de API REST, las aplicaciones cliente y servidor deben ser independientes entre sí. La única información que debe conocer la aplicación cliente es el URI del recurso solicitado; no puede interactuar con la aplicación servidor de ninguna otra forma. Del mismo modo, una aplicación de servidor no debe modificar la aplicación cliente más que pasarla a los datos solicitados a través de HTTP.

Las API REST no tienen estado, lo que significa que cada solicitud debe incluir toda la información necesaria para procesarla. En otras palabras, las API REST no requieren ninguna sesión del lado del servidor. Las aplicaciones de servidor no pueden almacenar ningún dato relacionado con una solicitud de cliente.

Cuando sea posible, los recursos deben poder almacenarse en caché en el lado del cliente o del servidor. Las respuestas del servidor también deben contener información sobre si se permite el almacenamiento en caché para el recurso entregado. El objetivo es mejorar el rendimiento en el lado del cliente y, al mismo tiempo, aumentar la escalabilidad en el lado del servidor.

En las API REST, las llamadas y respuestas pasan por diferentes capas. Como regla de oro, no asuma que las aplicaciones cliente y servidor se conectan directamente entre sí. Es posible que haya varios intermediarios diferentes en el circuito de comunicación. Las API REST deben diseñarse de tal manera que ni el cliente ni el servidor puedan saber si se comunica con la aplicación final o con un intermediario.

Por lo general las API REST envían recursos estáticos, pero, en algunos casos, las respuestas también pueden contener código ejecutable (como applets de Java). En estos casos, el código debe ejecutarse solo bajo demanda.

Las API REST se comunican a través de solicitudes HTTP para realizar funciones estándar de bases de datos, como crear, leer, actualizar y eliminar registros (también conocido como CRUD) dentro de un recurso.

Por ejemplo, una API REST usaría una solicitud GET para recuperar un registro. Una solicitud POST crea un nuevo registro. Una solicitud PUT actualiza un registro y una solicitud DELETE lo elimina. Todos los métodos HTTP se pueden utilizar en las llamadas a la API. Una API REST bien diseñada es similar a un sitio web que se ejecuta en un navegador web con funcionalidad HTTP incorporada.

El estado de un recurso en cualquier instante particular, o marca temporal, se conoce como representación de recursos. acc Esta información se puede entregar a un cliente en prácticamente cualquier formato, incluyendo JavaScript Object Notation (JSON), HTML, XLT, Python, PHP o texto plano. JSON es popular porque es legible tanto por humanos como por máquinas y es neutral en cuanto al lenguaje de programación.

Los encabezados y parámetros de solicitud también son importantes en las llamadas a la API REST, porque incluyen información importante del identificador, como metadatos, autorizaciones, identificadores de recursos uniformes (URI), almacenamiento en caché, cookies y más. Los encabezados de solicitud y los encabezados de respuesta, junto con los códigos de estado HTTP convencionales, se utilizan dentro de las API REST bien diseñadas.

GraphQL versus API REST: ¿Cuál es la diferencia?

Aunque la flexibilidad es una ventaja significativa del diseño de API REST, esa misma flexibilidad facilita el diseño de una API que no funciona o funciona mal. Por este motivo, los desarrolladores profesionales comparten las mejores prácticas en las especificaciones de la API REST.

La especificación OpenAPI (OAS) establece una interfaz para describir una API de manera que permita a cualquier desarrollador o aplicación descubrirla, y comprender completamente sus parámetros y capacidades. Esta información incluye endpoints disponibles, operaciones permitidas en cada endpoint, parámetros de operación, métodos de autenticación, entre otros. La última versión, OAS3, incluye herramientas prácticas, como el generador OpenAPI, para generar clientes API y stubs de servidor en diferentes lenguajes de programación.

La seguridad de una API REST también comienza con las mejores prácticas de la industria. Utilice algoritmos hash para la seguridad de las contraseñas y HTTPS para la transmisión segura de datos. Un marco de autorización como OAuth 2.0puede ayudar a limitar los privilegios de las aplicaciones de terceros.

Al usar una marca temporal en el encabezado HTTP, una API también puede rechazar cualquier solicitud que llegue después de un cierto periodo. La validación de parámetros y los tokens web JSON son otras formas de garantizar que solo los clientes autorizados puedan acceder a la API.