Saltar al contenido

Blog técnico | Categorización de la API

Las API son una parte integral de nuestro sistema distribuido aquí en . Las utilizamos para comunicarnos entre y dentro de contextos delimitados. Uno de los lemas de nuestro equipo de ingeniería es “Sé explícito”. Para ello, tenemos un sistema de categorización para las API que construimos y publicamos. Esto nos ayuda a saber para qué sirve la API y quién debería (y quién no) utilizarla.

Tenemos dos categorías ortogonales para los API. Tenemos APIs que encajan en (casi) todas las combinaciones posibles de estos conjuntos de categorías.

Blog técnico | Categorización de la API
Blog técnico | Categorización de la API

Visibilidad

Lo primero que tenemos que decidir sobre un API es si se puede acceder a él desde fuera de nuestro centro de datos.

Interno

Estas APIs sólo pueden ser accedidas desde servidores dentro de nuestro centro de datos. Todavía seguimos las mejores prácticas como el equilibrio de carga, etc., pero no proporcionamos ninguna ruta pública a estas APIs.

Público

Las API de esta categoría tienen rutas públicas y se puede acceder a ellas desde cualquier lugar.

Consumidor

La segunda pregunta que debe ser respondida es quién usará la API. Esta decisión afectará a muchas otras decisiones sobre las características del API.

Contexto

Este API sólo se utiliza dentro de un contexto limitado. Esta API no tiene que ser versionada explícitamente ya que un Contexto Limitado es manejado por un solo equipo y puede ser liberado como una unidad cuando sea necesario. Es probable que esta API cambie rápidamente a medida que evolucionen los consumidores dentro del Bounded Context.

Sistema

Este API se comparte entre Contextos Limitados. Cuando un Contexto Limitado necesita consultar sincronizadamente a otro, una API del sistema es la respuesta. En el sistema, esta API será un servicio de RESTful JSON para que pueda ser fácilmente consumido por las muchas pilas de tecnología que utilizamos.

Las versiones de este tipo de API deben ser coordinadas entre el equipo que apoya el Contexto Limitado que lo expone y los equipos que apoyan los Contextos Limitados que lo consumen. Sólo apoyamos tres versiones de cualquier API interno: vPrevious, vCurrent, vNext (que está actualmente en desarrollo). Esto permite a los equipos que publican las API del sistema evolucionar su parte del producto sin que el peso de las API heredadas acabe con su progreso. Si su equipo está consumiendo una API de vPrevious, debe priorizar la migración a vCurrent.

Cliente

Esta API está destinada o es compartida con clientes fuera de .

La creación de versiones es esencial, ya que no hay garantía de que los consumidores adopten las nuevas API a medida que se publiquen. Normalmente, este tipo de API se versionará más lentamente que los otros dos, ya que se requiere una mayor notificación para permitir a los consumidores públicos adaptarse a los nuevos contratos de API. No deberíamos admitir más de tres versiones de cualquier API de cliente: vPrevious, vCurrent, vNext (que se encuentra actualmente en desarrollo) aunque los responsables de productos de estas API pueden hacer excepciones si el beneficio para los clientes supera el coste de mantenimiento para el equipo de desarrollo del producto.

Categorías: technicalTags: architecture, APIs