Dominar la arquitectura API

Introducción

En esta introducción, descubrirás los fundamentos de las API y su potencial para formar parte del viaje de la arquitectura. Presentaremos una definición ligera de las API y su uso dentro y fuera del proceso. Para demostrar la importancia de las API, presentaremos el caso práctico del sistema de conferencias, un ejemplo en funcionamiento que evolucionará a lo largo del libro. Las API fuera de proceso te permiten pensar más allá de una simple arquitectura de tres niveles; para demostrarlo, introduciremos los patrones de tráfico y su importancia. Esbozaremos un resumen de los pasos del caso práctico, que te permitirá avanzar si un área te interesa directamente.

Para presentar las API y su ecosistema asociado, utilizaremos una serie de artefactos importantes. Presentaremos el caso práctico con diagramas del modelo C4 y revisaremos los detalles y la lógica del enfoque. También aprenderás sobre el uso de los Registros de Decisiones de Arquitectura (ADR) y el valor de definir claramente las decisiones a lo largo del ciclo de vida del software. Al final de la introducción, esbozaremos las Directrices ADR, nuestro enfoque para ayudarte a tomar decisiones cuando la respuesta es "depende".

El viaje de la arquitectura

Cualquiera que haya hecho un viaje largo se habrá encontrado sin duda con la pregunta (y posiblemente persistente) "¿hemos llegado ya?"En las primeras consultas, miras el GPS o un planificador de rutas y haces una estimación, esperando que no te encuentres con ningún retraso por el camino. De forma similar, el viaje hacia la construcción de arquitecturas basadas en API puede ser complejo de recorrer para los desarrolladores y arquitectos; aunque existiera un GPS de arquitectura, ¿cuál sería tu destino?

La arquitectura es un viaje sin destino, y no puedes predecir cómo cambiarán las tecnologías y los enfoques arquitectónicos. Por ejemplo, quizá no pudiste predecir que la tecnología de malla de servicios se utilizaría tan ampliamente, pero una vez que conozcas sus capacidades puede que te haga pensar en evolucionar tu arquitectura actual. No son sólo las tecnologías las que influyen en el cambio de la arquitectura; los nuevos requisitos y limitaciones empresariales también impulsan el cambio de dirección arquitectónica.

El efecto culminante de de ofrecer un valor incremental combinado con las nuevas tecnologías emergentes conduce al concepto de arquitectura evolutiva. La arquitectura evolutiva es un enfoque para cambiar incrementalmente una arquitectura, centrándose en la capacidad de cambiar con velocidad y reduciendo el riesgo de impactos negativos. Por el camino, te pedimos que tengas en cuenta los siguientes consejos al abordar la arquitectura API:

Aunque a los arquitectos nos gusta poder planificar estratégicamente el futuro, el ecosistema de desarrollo de software en constante cambio lo hace difícil. Como no podemos evitar el cambio, tenemos que aprovecharlo.

Construir arquitecturas evolutivas, de Neal Ford, Rebecca Parsons y Patrick Kua (O'Reilly)

En muchos proyectos, las propias API son evolutivas, y requieren cambios a medida que se integran más sistemas y servicios. La mayoría de los desarrolladores han creado servicios centrados en una única función, sin tener en cuenta la reutilización más amplia de la API desde la perspectiva del consumidor.

Diseño API-First es un enfoque en el que los desarrolladores y arquitectos tienen en cuenta la funcionalidad de su servicio y diseñan una API centrada en el consumidor. El consumidor de la API puede ser una aplicación móvil, otro servicio o incluso un cliente externo. En el Capítulo 1 repasaremos las técnicas de diseño para apoyar un enfoque API-First y descubriremos cómo construimos API duraderas al cambio y que aporten valor a una amplia base de consumidores.

La buena noticia es que puedes iniciar un viaje hacia una arquitectura basada en API en cualquier momento. Si eres responsable de un inventario técnico preexistente, te mostraremos técnicas para hacer evolucionar tu arquitectura con el fin de promover el uso de API en tu plataforma. Por otro lado, si tienes suerte y cuentas con un lienzo en blanco con el que trabajar, compartiremos contigo las ventajas de adoptar arquitecturas de API basadas en nuestros años de experiencia, al tiempo que destacaremos los factores clave en la toma de decisiones.

Breve introducción a las API

En el campo de la arquitectura de software, hay un puñado de términos que son increíblemente difíciles de definir. El término API, que significa interfaz de programación de aplicaciones, entra dentro de esta categorización, ya que el concepto surgió por primera vez hace nada menos que 80 años. Los términos que han existido durante una cantidad significativa de tiempo acaban sobreutilizándose y teniendo múltiples significados en diferentes espacios problemáticos. Consideramos que una API significa lo siguiente:

• Una API representa una abstracción de la implementación subyacente.

• Una API está representada por una especificación que introduce tipos. Los desarrolladores pueden entender las especificaciones y utilizar herramientas para generar código en varios lenguajes para implementar un consumidor de API (software que consume una API).

• Una API tiene una semántica o comportamiento definidos para modelar eficazmente el intercambio de información.

• Un diseño eficaz de la API permite la extensión a clientes o terceros para una integración empresarial.

A grandes rasgos, las API pueden dividirse en dos categorías generales, dependiendo de si la invocación a la API se realiza dentro o fuera del proceso. El proceso al que nos referimos aquí es un proceso del sistema operativo (SO). Por ejemplo, una invocación a un método Java de una clase a otra es una invocación a una API dentro del proceso, ya que la llamada la gestiona el mismo proceso desde el que se hizo la llamada. Una aplicación .NET que invoque a una API externa de tipo REST utilizando una biblioteca HTTP es una invocación a una API fuera de proceso, ya que la llamada es gestionada por un proceso externo adicional distinto del proceso desde el que se hizo la llamada. Normalmente, una llamada a una API fuera de proceso implicará que los datos atraviesen una red, potencialmente una red local, una red de nube privada virtual (VPC) o Internet. Nos centraremos en este último estilo de API; sin embargo, los arquitectos se encontrarán a menudo con la necesidad de remodelar una API dentro de proceso para convertirla en una API fuera de proceso. Para demostrar este concepto (y otros), crearemos un caso práctico en funcionamiento que evolucionará a lo largo del libro.

Ejemplo práctico: Caso práctico de Sistema de Conferencias

En hemos elegido modelar un sistema de conferencias para nuestro caso de estudio porque el dominio es fácilmente reconocible, pero también proporciona suficiente complejidad para modelar una arquitectura evolutiva.La Figura I-1 visualiza el sistema de conferencias en el nivel superior, lo que nos permite establecer el contexto de la arquitectura que estamos debatiendo. El sistema lo utiliza un cliente externo para crear su cuenta de asistente, revisar las sesiones de conferencias disponibles y reservar su asistencia.

Figura I-1. Diagrama contextual del sistema de conferencias C4

Ampliemos el cuadro del sistema de conferencias de la Figura I-2. Ampliar el sistema de conferencias nos proporciona más detalles sobre sus principales componentes técnicos. El cliente interactúa con la aplicación web, que invoca APIs en la aplicación de conferencias. La aplicación de conferencias utiliza SQL para consultar el almacén de datos de respaldo.

Figura I-2. Diagrama contenedor del sistema de conferencias C4

La Figura I-2 revela que, desde el punto de vista de la API, la funcionalidad más interesante está dentro del contenedor de la aplicación de conferencia.La Figura I-3 amplía este contenedor específico, permitiéndote explorar la estructura y las interacciones.

En el sistema actual intervienen cuatro componentes principales y la base de datos. El Controlador de la API se enfrenta a todo el tráfico entrante desde la interfaz de usuario y toma una decisión sobre hacia dónde encaminar la solicitud en el sistema. Este componente también sería responsable del marshaling desde la representación a nivel de red on the wire a un objeto o representación en código. El componente Controlador de la API es intrigante desde la perspectiva del enrutamiento dentro del proceso y actuando como un punto de unión o patrón de controlador frontal. Para las solicitudes y el procesamiento de la API, éste es un patrón importante; todas las solicitudes pasan por el controlador, que toma una decisión sobre hacia dónde se dirige la solicitud. En el Capítulo 3 estudiaremos la posibilidad de sacar al controlador fuera del proceso.

Los componentes de Asistentes, Reservas y Sesiones participan en la traducción de las solicitudes en consultas y ejecutan SQL contra la base de datos fuera de proceso. En la arquitectura existente, la base de datos es un componente importante, que puede imponer relaciones, por ejemplo, restricciones entre reservas y sesiones.

Figura I-3. Esquema de los componentes del sistema de conferencia C4

Ahora que hemos profundizado hasta el nivel de detalle adecuado, volvamos a examinar los tipos de interacciones de la API en el estudio de caso en este punto .

Tipos de API en la Conferencia Estudio de caso

En la Figura I-3, la flecha de la Aplicación Web al Controlador de la API es una llamada fuera de proceso, mientras que la flecha del Controlador de la API al Componente Asistente es un ejemplo de llamada dentro de proceso. Todas las interacciones dentro del límite de la Aplicación de la Conferencia son ejemplos de llamadas dentro de proceso. La invocación dentro de proceso está bien definida y restringida por el lenguaje de programación utilizado para implementar la Aplicación de la Conferencia. La invocación es segura en tiempo de compilación (las condiciones en las que se aplica el mecanismo de intercambio se cumplen en el momento de escribir el código).

Razones para cambiar el sistema de conferencias

El enfoque arquitectónico actual de ha funcionado para el sistema de conferencias durante muchos años, sin embargo, el propietario de la conferencia ha pedido tres mejoras, que están impulsando el cambio arquitectónico:

• A los organizadores de la conferencia les gustaría crear una aplicación móvil.

• Los organizadores de la conferencia tienen previsto globalizar su sistema, organizando decenas de conferencias en lugar de una al año. Para facilitar esta expansión, les gustaría integrarse con un sistema externo de Convocatoria de Ponencias (CFP) para gestionar a los ponentes y su solicitud para presentar sesiones en la conferencia.

• A los organizadores de la conferencia les gustaría desmantelar su centro de datos privado y, en su lugar, ejecutar el sistema de la conferencia en una plataforma en la nube de alcance mundial.

Nuestro objetivo es migrar el sistema de conferencias para que pueda soportar los nuevos requisitos, sin afectar al sistema de producción existente ni reescribirlo todo de una sola vez.

De la arquitectura por niveles al modelado de API

El punto de partida del estudio de caso es una arquitectura típica de tres niveles, compuesta por una interfaz de usuario, un nivel de procesamiento del lado del servidor y un almacén de datos. Para empezar a hablar de una arquitectura evolutiva necesitamos un modelo para pensar en la forma en que los componentes procesan las solicitudes de la API. Necesitamos un modelo/abstracción que funcione tanto para la nube pública como para las máquinas virtuales de un centro de datos y un enfoque híbrido.

La abstracción del tráfico nos permitirá considerar las interacciones fuera de proceso entre un consumidor de API y un servicio de API, a veces denominado productor de API. Con enfoques arquitectónicos como la arquitectura orientada a servicios (SOA) y la arquitectura basada en microservicios, la importancia de modelar las interacciones de API es fundamental. Aprender sobre el tráfico de API y el estilo de comunicación entre componentes será la diferencia entre aprovechar las ventajas de un mayor desacoplamiento o crear una pesadilla de mantenimiento.

Advertencia

Los patrones de tráfico son utilizados por los ingenieros de centros de datos para describir los intercambios de red dentro de los centros de datos y entre aplicaciones de bajo nivel. A nivel de API, utilizamos patrones de tráfico para describir flujos entre grupos de aplicaciones. A efectos de este libro, nos referimos a patrones de tráfico a nivel de aplicación y de API.

Caso práctico: Un paso evolutivo

Para empezar a considerar los tipos de patrones de tráfico, será útil dar un pequeño paso evolutivo en nuestra arquitectura del caso práctico. En la Figura I-4 se ha dado un paso para refactorizar el componente Asistente y convertirlo en un servicio independiente, en lugar de un paquete o módulo dentro del sistema de conferencias heredado. El sistema de conferencias tiene ahora dos flujos de tráfico: la interacción entre el cliente y el sistema de conferencias heredado y la interacción entre el sistema heredado y el sistema de asistentes.

Figura I-4. Paso evolutivo del contexto del sistema de conferencias C4

Tráfico Norte-Sur

En la Figura I-4, la interacción entre el cliente y el sistema de conferencias heredado se denomina tráfico norte-sur, y representa un flujo de entrada. El cliente está utilizando la interfaz de usuario, que envía solicitudes al sistema de conferencias heredado a través de Internet. Esto representa un punto de nuestra red que está expuesto públicamente y al que accederá la interfaz de usuario.¹ Esto significa que cualquier componente que gestione el tráfico norte-sur debe realizar comprobaciones concretas sobre la identidad del cliente y también incluir los desafíos apropiados antes de permitir que el tráfico progrese a través del sistema.El Capítulo 7 entrará en detalle sobre la seguridad del tráfico norte-sur de la API.

Tráfico este-oeste

La nueva interacción entre el sistema de conferencias heredado y el servicio de Asistentes introduce un flujo de tráfico este-oeste en nuestro sistema. El tráfico este-oeste puede considerarse como un estilo de comunicación de servicio a servicio dentro de un grupo de aplicaciones. La mayor parte del tráfico este-oeste, sobre todo si el origen está dentro de tu infraestructura más amplia, puede ser de confianza hasta cierto punto. Aunque podamos confiar en el origen del tráfico, sigue siendo necesario considerar la seguridad del tráfico este-oeste .

Infraestructura API y patrones de tráfico

Hay dos componentes clave de infraestructura presentes en las arquitecturas basadas en API, que son fundamentales para controlar el tráfico. Controlar y coordinar el tráfico suele describirse como gestión del tráfico. Generalmente, el tráfico norte-sur se controlará mediante pasarelas API, tema clave del Capítulo 3.

El tráfico este-oeste será gestionado a menudo por componentes de infraestructura como Kubernetes o la malla de servicios, tema clave del Capítulo 4. Los componentes de infraestructura como Kubernetes y la malla de servicios utilizan abstracciones de red para enrutar a los servicios, lo que requiere que los servicios se ejecuten dentro de un entorno gestionado. En algunos sistemas, el tráfico este-oeste es gestionado por la propia aplicación y se implementan técnicas de descubrimiento de servicios para localizar otros sistemas.

Hoja de ruta para la Conferencia Estudio de caso

A lo largo de observarás los siguientes cambios o aplicaciones de la tecnología al caso práctico:

• En el Capítulo 1 explorarás el diseño y la especificación de la API de Asistentes. También presentaremos la importancia de los intercambios de versiones y modelos para el rendimiento de la API de Asistentes.

• En el capítulo 2 explorarás las pruebas de contratos y componentes para verificar el comportamiento del servicio Asistente. También verás cómo los Testcontainers pueden ayudarte con las pruebas de integración.

• En el Capítulo 3 verás cómo exponer el servicio de Asistentes a los consumidores utilizando una pasarela API. También demostraremos cómo hacer evolucionar el sistema de conferencias utilizando una pasarela API en Kubernetes.

• En el Capítulo 4 refactorizaremos la funcionalidad de las sesiones del sistema de conferencias heredado utilizando una malla de servicios. También aprenderás cómo la malla de servicios ayuda con el enrutamiento, la observabilidad y la seguridad.

• En el Capítulo 5 hablaremos del marcado de características y de cómo puede ayudar a hacer evolucionar el sistema de conferencias y evitar una implementación y una liberación acopladas. También exploraremos enfoques para modelar las liberaciones en el sistema de conferencias y demostraremos el uso de Argo Rollouts para el servicio de Asistentes.

• En el Capítulo 6 explorarás cómo aplicar el modelado de amenazas y mitigar las preocupaciones de OWASP en el servicio de Asistentes.

• En el Capítulo 7 verás la autenticación y autorización y cómo se implementa para el servicio de Asistentes.

• En el capítulo 8 verás cómo establecer los límites del dominio del servicio de Asistente y cómo pueden ayudar los distintos patrones de servicio.

• En el Capítulo 9 verás la adopción de la nube y cómo trasladar el servicio de Asistentes a la nube y considerar la posibilidad de replanificación.

El estudio de caso y la hoja de ruta prevista requieren que visualicemos el cambio arquitectónico y registremos las decisiones. Se trata de artefactos importantes que ayudan a explicar y planificar los cambios en los proyectos de software. Creemos que los diagramas C4 y los Registros de Decisiones de Arquitectura (ADR) representan una forma clara de registrar el cambio .

Utilizar diagramas C4

Como parte de que presenta el estudio de caso, revelamos tres tipos de diagramas C4 del modelo C4. Creemos que el C4 es el mejor estándar de documentación para comunicar la arquitectura, el contexto y las interacciones a un conjunto diverso de partes interesadas. Quizá te preguntes qué pasa con el UML. El Lenguaje Unificado de Modelado (UML) proporciona un extenso dialecto para comunicar arquitecturas de software. Un reto importante es que la mayor parte de lo que proporciona el UML no se compromete con la memoria de arquitectos y desarrolladores, y la gente vuelve rápidamente a las cajas/círculos/diamantes. Entender la estructura de los diagramas antes de entrar en el contenido técnico de la discusión se convierte en un verdadero reto. Muchos diagramas sólo quedan grabados en el historial de un proyecto si alguien utiliza accidentalmente y por error un rotulador permanente en lugar de un rotulador de borrado en seco. El modelo C4 proporciona un conjunto simplificado de diagramas que actúan como guía de la arquitectura de tu proyecto en varios niveles de detalle.

Diagrama de contexto C4

La Figura I-1 se representa en utilizando un diagrama de contexto del modelo C4. La intención de este diagrama es establecer el contexto tanto para un público técnico como no técnico. Muchas conversaciones sobre arquitectura se sumergen directamente en los detalles de bajo nivel y pasan por alto establecer el contexto de las interacciones de alto nivel. Considera las implicaciones de equivocarse en un diagrama de contexto del sistema: la ventaja de resumir el enfoque puede ahorrar meses de trabajo para corregir un malentendido.

Diagrama del contenedor C4

Mientras que la Figura I-1 proporciona a el panorama general del sistema de conferencias, un diagrama contenedor ayuda a describir el desglose técnico de los principales participantes en la arquitectura. Un contenedor en C4 se define como "algo que tiene que estar funcionando para que funcione el sistema general" (por ejemplo, la base de datos de conferencias). Los diagramas contenedores son de naturaleza técnica y se basan en el diagrama de contexto del sistema de nivel superior.La Figura I-2, un diagrama contenedor, documenta el detalle de un cliente que interactúa con el sistema de conferencias.

Nota

El contenedor de la aplicación de conferencia de la Figura I-2 está documentado simplemente como software. Normalmente, un contenedor C4 proporcionaría más detalles sobre el tipo de contenedor (por ejemplo, Aplicación Java Spring). Sin embargo, en este libro evitaremos los detalles tecnológicos, a menos que ayuden a demostrar una solución concreta. La ventaja de las API y, de hecho, de las aplicaciones modernas es que existe una gran flexibilidad en el espacio de la solución.

Diagrama de componentes del C4

El diagrama de componentes C4 de la Figura I-3 ayuda a definir las funciones y responsabilidades dentro de cada contenedor, junto con las interacciones internas. Este diagrama es útil si se consulta el detalle de un contenedor, y también proporciona un mapa muy útil de la base de código. Piensa en la primera vez que empiezas a trabajar en un nuevo proyecto: navegar por una base de código autodocumentada es una forma de hacerlo, pero puede ser difícil unirlo todo. Un diagrama de componentes revela los detalles del lenguaje/pila que estás utilizando para construir tu software. Para seguir siendo agnósticos en cuanto a tecnología, hemos utilizado el término paquete/módulo.

Uso de los Registros de Decisión de Arquitectura

Como promotores de , arquitectos y, de hecho, humanos, todos nos hemos visto en la tesitura de hacernos la pregunta "¿en qué estaban pensando?"Si alguna vez has conducido por la M62 entre Leeds y Manchester, en el Reino Unido, puede que te haya desconcertado la construcción de la autopista. A medida que subes la colina por la autopista de tres carriles, ésta empieza a desviarse del contraflujo de tráfico, hasta que finalmente surge la Granja Scott Hall, rodeada de unos 15 acres de tierras de labranza enclavadas entre los vagones. La leyenda local de lo sucedido describía al propietario del terreno como obstinado y que se negaba a moverse o a ceder sus tierras, por lo que los ingenieros simplemente construyeron a su alrededor.² Cincuenta años después salió a la luz un documental que revelaba que la verdadera razón era una falla geológica bajo el terreno, por lo que la autopista tuvo que construirse así. Cuando la gente adivina por qué se hizo algo de una manera determinada, es de esperar que surjan rumores, humor y críticas.

En la arquitectura de software habrá muchas restricciones sobre las que tendremos que construir, por lo que es importante garantizar que nuestras decisiones queden registradas y sean transparentes. Las ADR ayudan a que las decisiones sean claras en la arquitectura de software.

Una de las cosas más difíciles de rastrear durante la vida de un proyecto es la motivación que hay detrás de ciertas decisiones. Una nueva persona que se incorpora a un proyecto puede sentirse perpleja, desconcertada, encantada o enfurecida por alguna decisión anterior.

Michael Nygard, creador del concepto ADR

Hay cuatro secciones clave en una ADR: estado, contexto, decisión y consecuencias. Una ADR se crea en estado de propuesta y, basándose en el debate, normalmente será aceptada o rechazada. También es posible que la decisión sea sustituida más adelante por una nueva ADR. El contexto ayuda a situar el escenario y a describir el problema o los límites en los que se tomará la decisión. Aunque crear una entrada de blog antes de la ADR y luego enlazar desde la ADR ayuda a la comunidad a seguir tu trabajo, el contexto no pretende ser una entrada de blog o una descripción detallada. La decisión expone claramente lo que piensas hacer y cómo piensas hacerlo. Todas las decisiones conllevan consecuencias o compensaciones en arquitectura, y a veces puede resultar increíblemente costoso equivocarse.

Al revisar una ADR es importante ver si estás de acuerdo con la decisión de la ADR o si hay un enfoque alternativo. Un enfoque alternativo que no se haya tenido en cuenta puede hacer que se rechace la ADR. Hay mucho valor en una ADR rechazada y la mayoría de los equipos optan por mantener las ADR inmutables para captar el cambio de perspectiva. Las ADR funcionan mejor cuando se presentan en un lugar donde los participantes clave puedan verlas, comentarlas y ayudar a que la ADR pase a aceptada.

Consejo

Una pregunta que nos hacen a menudo es: ¿en qué momento debe el equipo crear una ADR? Es útil asegurarse de que ha habido un debate previo a la ADR y de que el registro es el resultado del pensamiento colectivo del equipo. Publicar una ADR a la comunidad en general da la oportunidad de recibir comentarios más allá del equipo inmediato de.

Asistentes Evolución ADR

En la Figura I-4 tomamos la decisión de dar un paso evolutivo en la arquitectura del sistema de conferencias. Se trata de un cambio importante y justificaría una ADR.La Tabla I-1 es un ejemplo de ADR que podría haber propuesto el equipo de ingeniería propietario del sistema de conferencias.

Tabla I-1. ADR001 Separación de asistentes del sistema de conferencias heredado

Estado	Propuesta
Contexto	Los propietarios de la conferencia han solicitado dos nuevas funciones importantes para el actual sistema de conferencias que deben implantarse sin perturbar el sistema actual. El sistema de conferencias tendrá que evolucionar para admitir una aplicación móvil y una integración con un sistema externo de PPC. Tanto la aplicación móvil como el sistema externo de PPC tienen que poder acceder a los asistentes para registrar a los usuarios en el servicio de terceros.
Decisión	Daremos un paso evolutivo, como se documenta en la Figura I-4, para dividir el componente Asistente en un servicio independiente. Esto permitirá el desarrollo API-First contra el servicio Asistente y permitirá invocar la API desde el servicio de conferencia heredado. Esto también permitirá diseñar el acceso directo al servicio Asistente para proporcionar información del usuario al sistema externo de PPC.
Consecuencias	La llamada al servicio Attendee no estará fuera de proceso y puede introducir una latencia que habrá que probar. El servicio Attendee podría convertirse en un punto único de fallo en la arquitectura y puede que tengamos que tomar medidas para mitigar el impacto potencial de ejecutar un único servicio Attendee. Con el modelo previsto de múltiples consumidores para el servicio Attendee, tendremos que garantizar un buen diseño, versionado y pruebas para reducir los cambios de ruptura accidentales.

Algunas de las consecuencias del ADR son bastante importantes y sin duda requieren un debate más profundo. Vamos a aplazar algunas de las consecuencias a capítulos posteriores de .

Dominar el API: Directrices ADR

Dentro de Dominio de la Arquitectura de APIs, en proporcionaremos unas Directrices ADR que te ayudarán a recopilar preguntas importantes que debes plantearte cuando tomes decisiones sobre el tema que estemos tratando. Tomar decisiones sobre una arquitectura basada en APIs puede ser realmente difícil, y en muchas situaciones la respuesta es "depende". En lugar de decir que depende sin contexto, las Directrices ADR te ayudarán a describir de qué depende y te ayudarán a fundamentar tus decisiones. Las Directrices ADR pueden servirte como punto de referencia al que volver o para leer por adelantado si te enfrentas a un reto concreto. El Cuadro I-2 describe el formato de las Directrices ADR y lo que debes esperar de ellas.

Tabla I-2. Directriz ADR: Formato

Decisión	Describe una decisión que podrías tener que tomar al considerar un aspecto de este libro.
Puntos de debate	Esta sección ayuda a identificar las discusiones clave que deberías tener al tomar una decisión sobre la arquitectura de tu API. En esta sección revelaremos algunas de nuestras experiencias que pueden haber influido en la decisión. Te ayudaremos a identificar la información clave para fundamentar tu proceso de toma de decisiones.
Recomendaciones	Te haremos recomendaciones específicas que deberás tener en cuenta al crear tu ADR, explicándote los motivos por los que hacemos una recomendación concreta.

Resumen

En esta introducción hemos sentado las bases tanto con el caso práctico como con el enfoque que adoptaremos para hablar de las arquitecturas basadas en API:

• La arquitectura es un viaje sin fin, y las API pueden desempeñar un papel importante para ayudarla a evolucionar.

• Las API son una abstracción de la implementación y pueden estar en procesoo fuera de proceso. A menudo, los arquitectos se encuentran en la tesitura de evolucionar hacia API fuera de proceso, que es el objetivo de este libro.

• En esta introducción has visto un pequeño paso evolutivo para desglosar el servicio de Asistentes con el fin de abordar los próximos requisitos empresariales.

• Has visto los tres primeros niveles de los diagramas C4 y su importancia para compartir y comunicar la arquitectura.

• Las ADR proporcionan un valioso registro para tomar decisiones y tienen valor tanto presente como histórico en la vida de un proyecto.

• Has visto la estructura de las Directrices ADR que se utilizarán a lo largo del libro para facilitar la toma de decisiones.

Una vez tomada la decisión de separar el servicio de Asistentes del sistema de conferencias, exploraremos ahora las opciones para diseñar y especificar la API de Asistentes.

¹ La intención es que sea la IU la que acceda al punto de entrada. Sin embargo, está abierto a posibles exploits.

² Los rasgos locales de obstinación alimentaron esta probable explicación.