Post Top Ad

Your Ad Spot

martes, 21 de enero de 2020

Taxonomía de API explicada: los muchos tipos de API

Si bien no hay dos API exactamente iguales, tienden a compartir muchas características, desde características de diseño hasta formatos de datos. Mirar de cerca estos rasgos nos permite identificar distintos tipos de API, que podemos usar para establecer expectativas claras, discutir qué funciona (y qué no) y apegarse a las mejores prácticas relevantes.
El único problema es: no hay una sola forma de clasificar las API. Entonces, en este artículo, veremos cuatro taxonomías API básicas basadas en características técnicas y relacionadas con el negocio: aprovisionamiento, estilo de diseño, protocolo y formato de datos. Sin más preámbulos, estos son los muchos tipos de API que deberían ser útiles si está planeando, creando o administrando una API.

Tipos de API por aprovisionamiento: privado, socio, público

Una forma de clasificar las API se basa en su aprovisionamiento (en otras palabras, en quién puede usarlas). Las API públicas son las API con las que nos encontramos todos los días, y están diseñadas para ser utilizadas por el público en general del desarrollador. Estas API pueden ser gratuitas y de pago; Lo importante es que cualquiera puede registrarse para acceder.
El siguiente paso son las API de socios , que están diseñadas para ser utilizadas por un grupo selecto de desarrolladores registrados previamente. Se emplean comúnmente en mercados de plataformas, donde las claves API necesarias para el desarrollo solo se comparten con socios registrados.
Finalmente, hay API privadas , que están diseñadas para uso interno (dentro de una organización) solamente. Por ejemplo, un banco puede tener una API privada que puede leer el saldo de una cuenta y el historial de transacciones. Una API como esta puede simplificar enormemente el desarrollo de interfaces front-end, ¡pero definitivamente no debe compartirse con el público!
Relacionado:  Desarrollo de la mentalidad de API para API privadas, de socios y públicas

Tipos de API por estilo de diseño

Quizás la forma más perspicaz de clasificar las API es por su estilo arquitectónico. En este sentido, el tipo más popular de API es REST . REST, que significa transferencia de estado representacional , es un enfoque simple y basado en recursos para construir API. Los consumidores envían solicitudes GET para acceder a un recurso y solicitudes PUT, POST y DELETE para modificarlo.
GraphQL es un estilo de diseño alternativo que está creciendo rápidamente en popularidad A diferencia de REST, que se basa en recursos discretos y predefinidos, GraphQL permite al consumidor elegir la información que desea recibir (según los parámetros que tenga) especificando esa información en la solicitud. Esto corrige dos grandes limitaciones de REST: la recuperación de datos insuficientes, donde no se devuelven suficientes datos, y la recuperación excesiva, donde se devuelven demasiados datos.
Falcor es un estilo arquitectónico que a menudo se compara con GraphQL ya que también busca abordar las deficiencias de REST. La premisa básica de Falcor es que todos sus datos están representados en un solo objeto JSON (más sobre eso más adelante). Falcor también incluye la funcionalidad de referencia, que convierte el árbol de datos JSON en un mapa de datos.
RPC es otro estilo de diseño que vale la pena mencionar, ya que a menudo se confunde con REST. La gran distinción es que RPC está basado en acciones, mientras que REST está basado en recursos. Tomemos el ejemplo hipotético de un punto final utilizado para registrar cuentas de usuario: REST lograría esto con un recurso / accounts, mientras que RPC usaría un punto final / signup.
Vale la pena mencionar que SOAP , que en realidad es un protocolo de comunicación, a menudo se asocia con su propio estilo de diseño. Las API SOAP generalmente usan RPC como estilo de diseño, por lo que a menudo se yuxtaponen (arquitectónicamente) con REST.
Lea también: eBook: GraphQL o Bust

Tipos de API por protocolo

Otra forma de clasificar las API se basa en el protocolo que utilizan. Esta es una distinción mucho más complicada ya que los protocolos operan en diferentes niveles y no siempre son mutuamente excluyentes. El protocolo de comunicación más conocido y utilizado con mayor frecuencia es HTTP , que es una forma simple y efectiva de enviar y recibir mensajes. HTTP y su contraparte más segura HTTPS son los protocolos utilizados por la gran mayoría de las API.
HTTP es un protocolo fantástico en buenas condiciones, pero de lo contrario puede dejar algo que desear. MQTT, AMQP y CoAP son protocolos populares diseñados para abordar las deficiencias de HTTP. MQTT está diseñado para ser liviano, especialmente en términos de uso de ancho de banda. Además, este protocolo es asíncrono, lo que significa que los clientes no tienen que esperar una respuesta de un servidor lento. AMQP ofrece los mismos beneficios, pero con un conjunto de funcionalidades mejor desarrollado. Finalmente, CoAP también está diseñado para operar bajo restricciones de velocidad y tamaño (esa es la c en CoAP) y combina bien con HTTP.
Otro protocolo que debe tener en cuenta es SOAP , que se encuentra en una categoría ligeramente diferente a los protocolos de comunicación anteriores. SOAP define cómo se deben enviar los datos utilizando un lenguaje de marcado llamado XML. A menudo funciona a través de HTTP, pero también puede usar otros protocolos como AMQP. Desafortunadamente, SOAP se ha asociado con un enfoque anticuado y anticuado para diseñar API.

Tipos de API por formato de datos

Mencionamos XML arriba, que es un ejemplo de un formato de datos que las API usan a menudo. El principal beneficio de los formatos de datos como XML es que son legibles tanto por humanos como por máquinas. El propio XML tiene una amplia gama de características, pero es criticado por su gran peso.
Aquí hay un ejemplo de una entrada XML simple:
JSON es una alternativa un poco más limpia, pero más limitada a XML. Es más rápido leer y escribir en la mayoría de las circunstancias y utiliza una estructura simple de pares clave-valor. Una alternativa aún más fácil a JSON es YAML , que sigue siendo lo suficientemente potente como para la mayoría de los casos de uso.
Aquí está el mismo ejemplo formateado en JSON:
... y aquí está en YAML:
Si bien estos son algunos de los formatos de datos más comunes en el diseño de API, hay muchos más por ahí .

Conclusión

Al hacer clic en este artículo, puede haber esperado que solo haya unos pocos "tipos" de API para familiarizarse. Ahora que sabe que hay tantas maneras de clasificar las API, puede ver por qué esto no es tan fácil. Dicho esto, es fácil clasificar las API por sus reglas de aprovisionamiento o formatos de datos; desafortunadamente, es un poco más complicado hacerlo por protocolo o estilo arquitectónico, ¡pero aún es muy posible!

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas