Header Ads Widget

Ticker

6/recent/ticker-posts

La evolución del mercado de API


 A la gente le encantan los mercados. Fuera de línea, en la feria de invierno o en el zoco, los mercados brindan a los consumidores la posibilidad de buscar los productos que les gustan y regatear el precio. ¿Quién no ama las gangas ? Los mercados en línea, como los sitios web de comparación de precios, mantienen esta tradición, lo que permite a los consumidores encontrar las mejores ofertas para seguros, tarjetas de crédito, etc.

Con la creciente importancia de los directorios de API , tiene sentido que los desarrolladores también deban tener una experiencia de mercado similar no solo para descubrir API, sino para encontrar la oferta más rentable para su elección de funciones de API.

Los mercados de API como RapidAPI , Hitch y API List permiten a los desarrolladores buscar las API que desean consumir. En estos sitios de agregación, los visitantes a menudo pueden aprender sobre la funcionalidad de la API, probar llamadas e inscribirse en una gran variedad de proveedores de API.

Sin embargo, este es solo un lado del atractivo de un mercado de API evolucionado . Para que los desarrolladores obtengan el máximo provecho de su inversión, ¿podrán alguna vez regatear el precio en estos sitios? ¿Cómo evolucionarán estos directorios hacia las continuas y matizadas necesidades de los desarrolladores?

En esta publicación, analizamos cómo podrían progresar los mercados de API y si realmente ofrecerán más opciones para los consumidores de API.

Portal vs Marketplace

Antes de hablar sobre un mercado de API evolucionado, vale la pena aclarar las diferencias entre un portal de API y un mercado . Esto enfatizará cómo un mercado agrega valor a la experiencia del desarrollador.

Los portales de API , ya sea un esfuerzo propio o un producto de gestión de API basado en plantillas , han sido un elemento básico de API Economy durante varios años. Los portales son implementados por un único proveedor de API y permiten a los desarrolladores comprender, integrarse e implementar contra las API del proveedor. Entregan documentación de API (generalmente junto con una especificación de API) e incluyen características como exploradores interactivos y tutoriales . También permiten a los desarrolladores incorporarse de forma segura al proveedor de API mediante la creación de claves de API o credenciales de OAuth .

Los mercados se diferencian de los portales en que agregan muchos proveedores de API en una sola vista y normalmente agregan funciones de búsqueda para que los desarrolladores puedan explorar muchas API diferentes. Las API a menudo se clasifican por área de enfoque (finanzas, redes sociales, contabilidad, etc.). Mashape es un ejemplo de este tipo de funcionalidad:

El atractivo de usar un mercado es uno de simplicidad . Los desarrolladores pueden acudir a un lugar para la mayoría de sus necesidades como consumidores de API. Esta atracción se despierta con características de valor agregado como la agregación de webhooks (como lo lanzó recientemente RapidAPI ), incorporación de API integrada, soporte centralizado y seguimiento de problemas. Al utilizar estas funciones, los desarrolladores solo necesitan realizar una integración en muchos proveedores de API.

El enfoque también tiene aspectos positivos para los proveedores de API. Ser parte de un mercado puede aumentar la exposición de sus API, especialmente para desarrolladores y proveedores más pequeños sin una gran presencia en el mercado. Para algunos proveedores, la implementación en un mercado puede significar prescindir de un portal por completo; simplemente necesitan proporcionar una especificación de API y están listos para funcionar.

Sin embargo, si muchos proveedores de API de la competencia participan en los mercados, ¿cómo diferencian los desarrolladores entre servicios similares para encontrar valor? Y, por otro lado, ¿cómo hacen los proveedores de API para que sus ofertas se destaquen entre la multitud? Por ejemplo, si hay 10 API de pago en el mercado, ¿cómo sabe un desarrollador cuál es la mejor? Aquí es donde comienza a tomar forma la idea de un mercado de API evolucionado.

Relacionado: ¿Qué es un portal API?

Beneficios de un mercado de API evolucionado

Un mercado de API evolucionado tendría tres características clave que lo diferencian de las ofertas actuales:

  • Un sistema de clasificación mejorado que ayuda a crear una vista más sofisticada de las API en el mercado. Este sistema permitiría capacidades de búsqueda contextual o incluso semántica.
    * Soporte para búsqueda tanto por aplicaciones como por humanos. En última instancia, esto significa proporcionar una API de búsqueda (REST, GraphQL o de otro tipo) que se puede utilizar para interrogar al mercado.
  • Soporte para la integración a nivel de aplicación, es decir, se puede seleccionar una API del mercado en función de los resultados de la búsqueda e integrarla automáticamente.

Este tipo de funcionalidad tiene muchos beneficios . Para los consumidores , obviamente existe una mayor elección al tener resultados de búsqueda relevantes y específicos que los guíen a la API con las funciones que realmente desean. Buscando API con un plan de precios específico, modelo de suscripcióno de lo contrario será mucho más fácil. Además, los consumidores también podrán incorporar y probar API automáticamente sin tener que depender de pasos manuales en muchos proveedores de API diferentes. En su forma más sofisticada, esto podría significar que los consumidores de API pueden realizar una incorporación justo a tiempo como reacción a cambios en el mercado, como recortes de precios o promociones. Esto reducirá el bloqueo de los consumidores de API y ofrecerá opciones reales en el mercado, con la posibilidad de que las aplicaciones actúen de forma autónoma en función de la intención de sus creadores o de las condiciones del mercado.

También habrá beneficios para los proveedores de API Podrán comercializar sus API basándose en los mismos atributos que los consumidores de API y sus aplicaciones pueden buscar. Por lo tanto, elegir una API se convertirá más en un caso de las características de la API como producto en lugar de elegir una API basada en la implementación de la tecnología. Este enfoque nivela el campo de juego para los proveedores de API. Pueden competir en los atributos de su producto y no en los caprichos de los juicios subjetivos de los desarrolladores y su visión de las opciones tecnológicas.

Los proveedores también podrán interrogar al mercado y buscar formas de remodelar sus ofertas para obtener una ventaja competitiva. Si bien tales capacidades tienen sus amenazas, para los valientes significa realmente ofrecer a los clientes lo que quieren al comprender su intención más profundamente. Ejecutar una promoción en su API, de la misma manera que las empresas lo hacen con productos físicos en una tienda física, se convierte en una posibilidad real.

Ejemplo

Es relativamente sencillo armar un prototipo de un aspecto del mercado evolucionado; el de descubrimiento e inscripción automatizados . Esto se puede hacer utilizando tecnologías y protocolos existentes.

En este ejemplo, no hay un producto de mercado de API específico, ya que asumimos que uno de los productos que ya hemos mencionado podría diseñarse para admitir esto.

En este prototipo se despliegan cuatro componentes clave:

  • Un mercado de API con un punto final GraphQL que permite a los consumidores de API consultar el tipo de API que desean utilizar.
  • Una especificación de OpenAPI que describe una API de intercambio de divisas que incluye un punto final conocido.
  • Una implementación de un punto final OpenID Connect Discovery .
  • Una implementación del Protocolo de registro de cliente dinámico OAuth 2.0 .

Tenga en cuenta que, en aras de la brevedad, este prototipo ignora intencionadamente el mecanismo para clasificar las API en el mercado.

En este escenario, una plataforma de cambio de divisas busca automáticamente en nuestro mercado una API de cambio de divisas con algunos criterios determinados, a saber, una tarifa por clic del 1% del valor de la transacción y un rendimiento admitido de 1000 TPS. Una API de este tipo ofrecería al propietario de la aplicación una reducción de costes que, a su vez, le permitiría ofrecer precios más competitivos a sus consumidores finales.

La plataforma de divisas envía la siguiente consulta en el punto final de GraphQL para buscar dicho proveedor.

{
  Apis(filter: {
      subject: FX,
      feeType: per-click,
      chargeThreshold: 1%
      }) {
    name
    specification
  }
}

El resultado devuelve un proveedor de API, RightONFX, que tiene atributos coincidentes y un enlace a su especificación Swagger.

{
"data": { "Api": { "name": "RightOnFX", "specification": "https://rightonfx.nowhere/swagger.json" } } }

La aplicación genera por sí misma un cliente basado en la especificación OpenAPI. También detecta que la especificación (la versión abreviada que se muestra a continuación) incluye un extremo conocido que cumple con el protocolo de descubrimiento de OpenID Connect:

{
"swagger": "2.0", "info": { "description": "The RightONFX API", "version": "2.0", "title": "API Explorer" }, "host": "https://rightonfx.nowhere" "basePath": "/", "consumes": [ "application/json" ], "produces": [ "application/json" ], "paths": { "/.well-known/openid-configuration": { "get": { "responses": { "200": { "description": "OpenID configuration information" } } } } } }

El protocolo Discovery permite que los clientes potenciales recuperen la información de configuración sobre un proveedor de OpenID e incluye los puntos finales que permiten a un cliente cómo registrarse como cliente de OpenID del proveedor. El mercado le otorga a la aplicación un token temporal para acceder a este punto final y al punto final de registro que describe.

Con el token, la aplicación usa el punto final de registro dinámico definido en la configuración conocida para registrar su aplicación como un cliente OAuth 2.0 . La solicitud de registro devuelve un ID de cliente y un secreto de cliente. El cliente de agregación ahora tiene todo lo que necesita para comenzar a realizar solicitudes a la API RightOnFX.

Pensamientos finales

Un mercado evolucionado para API parece ser una progresión lógica para la Economía de API . Algunos pueden argumentar que este estilo de mercado es una capa de agregación para API que va en contra de todo lo que representa el estilo arquitectónico descentralizado. Un mercado evolucionado también requerirá un sistema de clasificación justo y equitativo que evite que las prácticas hegemónicas (por parte del proveedor del mercado de API) entren y reduzcan la elección del consumidor.

En nuestro ejemplo, los criterios de búsqueda son bastante inequívocos, pero si se confía en la búsqueda semántica, existe la posibilidad de que la subjetividad se cuele cuando se interpretan los términos de búsqueda. También existe el desafío de crear un sistema de clasificación aceptado, algo que antes era difícil en las comunidades de Internet.

Nuestro prototipo obviamente tiene sus fallas, más específicamente en cómo el cliente generado se integra en la plataforma de divisas y si se aceptan los términos y condiciones (intensificar RegTech para proporcionar esto a nivel de máquina). Sin embargo, muestra la facilidad con que se podría construir un enfoque de aprovisionamiento automatizado, impulsado desde un mercado de API, basado en las tecnologías disponibles.

Muchos consumidores de API agradecen la elección y la simplicidad . Los proveedores de soluciones de software en general están satisfaciendo la demanda de facilidad de uso al producir tecnologías de rompecabezas que se pueden ensamblar fácilmente en una solución. Reducir los problemas de integración para los consumidores de API es coherente con este movimiento, y los proveedores de API lo adoptarán como un medio para vender sus productos más fácilmente. Este enfoque solo puede beneficiar a la economía API y su crecimiento continuo.

Publicar un comentario

0 Comentarios