Header Ads Widget

Ticker

6/recent/ticker-posts

Explicación de la taxonomía de API: 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. Observar 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 ceñirnos a las mejores prácticas relevantes.

El único problema es: no hay una única forma de categorizar 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, aquí están los muchos tipos de API que deberían ser útiles si está planeando, construyendo o administrando una API.

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

Una forma de categorizar 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, lo adivinó, el público general de desarrolladores. Estas API pueden ser gratuitas y de pago; lo importante es que cualquiera pueda registrarse para acceder.

Lo siguiente 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 los 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) únicamente. 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 reveladora de categorizar las API es por su estilo arquitectónico. En este sentido, el tipo de API más popular es REST . REST, que significa transferencia de estado representacional , es un enfoque simple y basado en recursos para crear API. Los consumidores envían solicitudes GET para acceder a un recurso y solicitudes PUT, POST y DELETE para modificarlo.

Un estilo de diseño alternativo que está creciendo rápidamente en popularidad es GraphQL . 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: captura insuficiente, donde no se devuelven suficientes datos, y 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 esto 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 diferencia es que RPC se basa en acciones, mientras que REST se basa en recursos. Tome 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 utilizarí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 de 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 categorizar 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 se excluyen mutuamente. El protocolo de comunicación más conocido y utilizado es HTTP , que es una forma sencilla y eficaz de enviar y recibir mensajes. HTTP y su homólogo más seguro HTTPS son los protocolos utilizados por la gran mayoría de API.

HTTP es un protocolo fantástico en buenas condiciones, pero de lo contrario puede dejar algo que desear. MQTT, AMQP y CoAP son todos 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 funciones 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 se adapta bien a HTTP.

Otro protocolo que debe conocer 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 mediante un lenguaje de marcado llamado XML. A menudo opera a través de HTTP, pero también puede utilizar otros protocolos como AMQP. Desafortunadamente, SOAP se ha asociado con un enfoque torpe y de la vieja escuela para diseñar API.

Tipos de API por formato de datos

Mencionamos XML anteriormente, que es un ejemplo de un formato de datos que las API utilizan a menudo. El principal beneficio de los formatos de datos como XML es que son legibles tanto por humanos como por máquinas. XML en sí mismo tiene una amplia gama de características, pero es criticado por su peso.

A continuación, se muestra un ejemplo de una entrada XML simple:

Thomas Bush 2019 provisioning design styles protocols data format

JSON es una alternativa un poco más limpia, pero más limitada, a XML. Es más rápido de leer y escribir en la mayoría de circunstancias y utiliza una estructura de par clave-valor simple. Una alternativa aún más fácil a JSON es YAML , que sigue siendo lo suficientemente potente para la mayoría de los casos de uso.

Aquí está el mismo ejemplo formateado en JSON:

{
  "article": {
    "author": "Thomas Bush",
    "title": "API Taxonomies Explained",
    "year": 2019,
    "topics": [
      "provisioning",
      "design styles",
      "protocols",
      "data formats"
    ]
  }

... y aquí está en YAML:

article:
author: Thomas Bush title: API Taxonomies Explained year: 2019 topics: - provisioning - design styles - protocols - data formats

Si bien estos son algunos de los formatos de datos más comunes en el diseño de API, existen muchos más .

Conclusión

Al hacer clic en este artículo, es posible que haya esperado que haya algunos "tipos" de API con los que familiarizarse. Ahora que sabe que hay tantas formas de categorizar 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!

Publicar un comentario

0 Comentarios