Primer enfoque de API o ¿por qué las API son importantes?
Hoy en día existe una creciente necesidad de compartir una gran cantidad de datos entre varias organizaciones, departamentos, dispositivos y personas comunes.
Una herramienta clave para satisfacer estas necesidades son definitivamente las API. API significa interfaz de programación de aplicaciones, es una puerta o una ventana en un programa de software. Actúa como un centro de servicio de datos robusto y escalable, nada más ni menos que eso.
El primer enfoque de API es el enfoque en el que el desarrollador construye primero la API y además de esa aplicación web API. Además, las aplicaciones móviles también se crean sobre la misma API. Al construir sobre API con los desarrolladores en mente, la compañía reduce el tiempo de desarrollo y libera a los desarrolladores de escribir código redundante.
Las tendencias muestran que la mayoría de las empresas de TI están utilizando este enfoque y la mayoría de las aplicaciones web se están convirtiendo en API web. También hay conceptos modernos como IoT (Internet de las cosas), que es básicamente la interconexión de dispositivos físicos, vehículos, edificios y electrodomésticos, como el refrigerador o la estufa.
Con eso en mente, es obvio que las API son el futuro del desarrollo web y es realmente importante estandarizar la forma de hacer API.
API RESTful
Hoy en día no existe un estándar firmemente definido para escribir API, pero hay algunas pautas de estilo. El estilo de arquitectura más popular y ampliamente utilizado es REST (transferencia de estado de representación). Los principios REST se basan en:
- Comunicación del servidor del cliente
La arquitectura cliente-servidor tiene una separación muy clara de preocupaciones, con la migración de la mayor parte del inicio de sesión empresarial del servidor al cliente. El servidor permanece solo como centro de servicio de datos, con el objetivo de ser rápido y confiable.
El servidor debe poder comprender completamente la solicitud del cliente sin usar ningún contexto de servidor o estado de sesión del servidor. Se deduce que todo el estado debe mantenerse en el cliente.
Todos los componentes deben interactuar a través de una única interfaz uniforme. Debido a que la interacción de todos los componentes ocurre a través de esta interfaz, la interacción con diferentes servicios es muy simple. La interfaz es la misma. Esto también significa que los cambios de implementación se pueden realizar de forma aislada. Tales cambios no afectarán la interacción del componente fundamental porque la interfaz uniforme siempre no cambia.
La compensación para toda esta flexibilidad es la falta de estándares bien establecidos. REST realmente describe el método por el cual se transfieren los datos, pero los implementadores se han quedado principalmente solos para averiguar cómo deberían verse estos datos.
Modelo de madurez de Richardson
El modelo de madurez de Richardson es una forma de calificar su API de acuerdo con las restricciones de REST. Cuanto mejor se adhiera la API a estas restricciones, mayor será su puntaje.
Esquema del modelo de madurez de Richardson
El punto de partida para el modelo de madurez es usar HTTP puramente como sistema de transporte para interacciones remotas, pero sin usar ninguno de los mecanismos de la web. Es decir, canaliza las solicitudes y respuestas a través de su protocolo sin usar el protocolo para indicar el estado de la aplicación. Utilizará solo un punto final y un solo tipo de método (en este nivel, generalmente POST)
En este nivel, el objetivo es introducir recursos. Entonces, en lugar de hacer todas las solicitudes a un punto final de servicio singular, ahora estamos hablando de recursos individuales. El recurso suele ser un centavo de datos en la aplicación web, o un modelo en un patrón MVC. Este nivel utiliza múltiples URI (puntos finales) donde cada URI es el punto de entrada a un recurso específico. En lugar de pasar por http://example.com/articles , es posible distinguir entre http://example.com/article/1 y http://example.com/article/2 . Este nivel todavía usa un solo método como POST
Este nivel estandariza el uso de verbos HTTP para realizar acciones. Este nivel indica que la API debe usar las propiedades del protocolo para lidiar con la escalabilidad y las fallas.
Los verbos HTTP básicos que se utilizan principalmente son GET y POST. HTTP define GET como una operación segura que no realiza ningún cambio significativo en el estado de nada. Esto nos permite invocar GET de forma segura cualquier cantidad de veces en cualquier orden y obtener el mismo resultado cada vez. Por otro lado, el método POST cambia el estado. Aproximadamente podemos decir que los métodos POST se utilizan para enviar información al servidor y escribirlos en la base de datos (cambiar el estado de la base de datos), y GET se utiliza para recuperar datos sin realizar ningún cambio en el estado del servidor, incluso si estamos enviando algunos parámetros de datos. con GET.
Otros verbos HTTP ampliamente utilizados incluyen PUT, PATCH, DELETE. PUT y PATCH se usan para actualizar recursos, la única diferencia es que PUT actualiza todo el recurso mientras que PATCH se usa para actualizaciones parciales. PUT se considera idempotente y seguro porque no cambia el estado del servidor (no crea nuevos recursos), mientras que PATCH no se considera idempotente de forma predeterminada.
El verbo DELETE se usa para eliminar operaciones. ELIMINAR también se considera una operación idempotente.
Además de los verbos HTTP, otra novedad en este nivel incluye el uso de códigos de estado como controlador de un flujo de trabajo del cliente. Si una solicitud GET fue exitosa, el código de estado de respuesta debe ser 200 (OK), si hubo algún código de estado de error, debe establecerse en consecuencia (500) para que la aplicación cliente pueda mostrar un mensaje de error o cualquier otra acción necesaria.
- NIVEL 3: Controles hipermedia (HATEOAS)
{"data": [{"products": [{"product_id": "76124", "name": "The Amazing Widget", "weight": "7.2 oz", ... "_links": [{" rel ":" self "," href ":" http://api.example.com/v1/products/76124 "," method ":" GET "}, {" rel ":" http: // api. ejemplo.com/v1/fabricantes/definición "," href ":" http://api.example.com/v1/manufactura/7 "," método ":" OBTENER "}, ...]}]}] }
Ejemplo de enlaces hipermedia
El objetivo de los controles hipermedia es que nos dicen qué podemos hacer a continuación y el URI del recurso que necesitamos manipular para hacerlo. En lugar de tener que saber dónde publicar nuestra solicitud de cita, los controles de hipermedios en la respuesta nos dicen cómo hacerlo.
Una ventaja es que permite que el servidor cambie su esquema de URI sin interrumpir a los clientes. Del mismo modo, ayuda a los desarrolladores de clientes a explorar el protocolo. Los enlaces dan a los desarrolladores de clientes una pista sobre lo que puede ser posible a continuación.
Conclusión
Las API son el futuro del desarrollo web, futuro que se acerca a una velocidad realmente rápida. Se necesita más estandarización que nunca. Como desarrollador, creo que el modelo de madurez de Richardson es un camino a seguir para hacer que su API sea más estandarizada y más RESTfull.