Para implementar la API, se necesita mucho trabajo. La planificación excesiva puede ser un desperdicio de energía, y su falta conduce a consecuencias desastrosas. En este libro, recibirá soluciones que le permitirán asignar los recursos necesarios y alcanzar el nivel de eficiencia requerido en el momento óptimo. ¿Cómo equilibrar la flexibilidad y el rendimiento manteniendo la fiabilidad y la facilidad de configuración? Cuatro expertos de la Academia API explican a los desarrolladores de software, gerentes de productos y proyectos cómo maximizar el valor de sus API mediante la administración de interfaces como productos de vida continua.
El material del libro se basa en nuestro conocimiento colectivo (Mehdi Mejuy, Eric Wilde, Ronnie Mitra, Mike Amundsen) durante muchos años de crear, desarrollar y mejorar la API, tanto la nuestra como la de otros. Expone toda nuestra experiencia. Identificamos dos factores clave para el desarrollo eficaz de API: la necesidad de un enfoque orientado al producto y la formación del equipo adecuado. También identificamos tres factores importantes para administrar este trabajo: liderazgo, desarrollo de productos y desarrollo de sistemas API.
Estos cinco elementos forman la base sobre la cual construir un exitoso programa de administración de API. Presentamos al lector todos estos temas y brindamos orientación sobre cómo encajarlos en el contexto de su organización.
Extracto Sistemas API
Con la creciente funcionalidad de la API, cada vez es más importante administrar programas en desarrollo para que los beneficios y el valor de todo el conjunto de API de la organización crezcan tanto como sea posible. Debe recordar este equilibrio, porque la mejor (o relativamente buena) manera de proporcionar un servicio individual utilizando la API puede no ser tan útil si lo mira desde el punto de vista de la facilidad de usar este servicio como parte de un sistema común.
Los sistemas API modernos crecen constantemente en términos del número total de API, así como del número de API utilizadas por los nuevos servicios. Dado este aumento en las interdependencias, entendemos que sería útil si los desarrolladores de nuevos servicios no tuvieran que comprender diseños API completamente diferentes y aplicarlos. Las diferencias pueden ser dramáticas, por ejemplo, si la API utiliza un REST o un estilo orientado a eventos (consulte la sección Diseño de la sección Introducción a los pilares del Capítulo 4), pero incluso si los estilos coinciden, se pueden detectar diferencias como el uso del formato JSON. o XML.
Desde el punto de vista de un usuario de API, también sería útil tener una terminología común. Por ejemplo, si usa varias API que proporcionan datos de usuario en cualquier forma, será más fácil si todas tienen un modelo de usuario principal (incluso si se presenta de manera ligeramente diferente, sin embargo, es útil tener un modelo común para diferentes servicios) .
La idea de los beneficios de la estandarización indica claramente que cuanto más es, mejor. Hasta cierto punto lo es, pero al mismo tiempo se sabe que la estandarización requiere tiempo y recursos, por lo general no se reduce al "único modelo verdadero y mejor", sino que simplemente crea un modelo con el que todos pueden llegar a un acuerdo y, por lo tanto, en general, esta inversión tiene riesgos y ventajas.
Quizás el uso de un formato único para cada API no sea la mejor solución, es más razonable elegir entre los existentes, por ejemplo, JSON o XML. En este caso, los beneficios de aplicar los estándares existentes superan los beneficios probables de formatos únicos. Sin embargo, puede ser muy costoso estandarizar algunos elementos de diferentes servicios, por ejemplo, el modelo de usuario ya mencionado. En este caso, es lógico no recurrir a gastos tan injustificados en aras de encontrar el único modelo de usuario verdadero y simplemente detenerse en el modelo de dominio.
En términos generales, idealmente para cada servicio, no queremos reinventar la rueda cuando no sea necesario, sino reutilizar los elementos de diseño que reducen el costo de los recursos para crear un diseño, su comprensión e implementación. Si podemos lograr un nivel tan ideal de reaplicación, o al menos acercarnos a él, esto permitirá a los creadores de servicios enfocarse en aquellos aspectos del diseño que deben enfocarse sin distraerse por problemas ya resueltos.
Vemos que más y más organizaciones hacen precisamente eso. Pero lo más importante en esto es comprender y asegurarse de que los manuales para diseñadores se actualicen constantemente: se evalúan y aprueban nuevos métodos, los métodos antiguos salen de circulación y la principal fuerza impulsora detrás de estos cambios es el conjunto de métodos API en constante evolución en la organización.
Es importante comprender que el sistema API es un entorno móvil y en constante cambio, y para que continúe funcionando, la arquitectura debe seguir el mismo camino de desarrollo continuo. Luego se convierte en un sistema a gran escala, por ejemplo, Internet, que, por un lado, funciona todo el tiempo, y por otro lado, está en constante cambio y constantemente aparecen nuevos estándares y tecnologías.
API de arqueología
Aunque ahora vemos una gran cantidad de organizaciones que recién comienzan a crear programas con API, es importante recordar que en cualquier organización que usó tecnología de la información, es casi seguro que hay algunas API que se han utilizado durante mucho tiempo.
Según la definición, una API es cualquier interfaz que permite que dos componentes de software interactúen. Si reduce la definición a una comprensión moderna de la API de red, entonces esta es cualquier interfaz que permite que dos componentes de software interactúen a través de la red.
En muchas organizaciones, tales interfaces no se llaman API, y no están diseñadas para ser reutilizadas (recuerde la historia sobre la famosa carta API de Jeff Bezos, que contamos en la subsección de Bezos Charter de la sección Design Thinking del Capítulo 3). Pero la mayoría de las veces existen estas interfaces, incluso si fueron creadas y utilizadas para la integración solo para un solo uso (socavando esta una de las principales propiedades útiles de la API: la posibilidad de reutilización).
Encontrar y aplicar tales proto-API puede ser útil porque muestra dónde apareció la necesidad de integración (incluso si se creó utilizando métodos que no cumplían con los objetivos de la API). No todas estas proto-API deben reemplazarse por API convencionales, pero solo al comprender el historial, puede obtener ideas sobre cómo se observó la necesidad de integración, qué se hizo en esta área y dónde puede aparecer la necesidad de integración adicional.
API PROTO
La necesidad de la interacción de componentes existe en todos los sistemas complejos que consisten en partes separadas. Una API es una forma de hacerlo, pero hay muchas otras. Desde el punto de vista de la API, cualquier mecanismo utilizado para la interacción de componentes que no sea una API puede considerarse una proto-API. En un sistema ideal, utilizando la API, todas las interacciones de los componentes se realizan sin excepción. Si recuerda esta imagen ideal, cualquier interacción sin la ayuda de la API se convierte en candidato para la modernización, para ser reemplazada por una API. Por lo tanto, cualquier mecanismo para la interacción de componentes sin la ayuda de una API puede considerarse una proto-API.
En general, la arqueología API puede ayudarlo a comprender mejor el sistema API, incluso si ahora consiste principalmente en proto-API. Proporciona un punto de partida para comprender la necesidad de integración que ha surgido en el pasado y para qué inversiones de API puede desentrañar mejor la red problemática de muchas integraciones de usuarios. Con experiencia y con el tiempo, reemplazar las integraciones creadas antes del advenimiento de la API con modelos modernos es cada vez más fácil.
Gestión de API a gran escala
La administración de API a gran escala es el acto de equilibrio entre la introducción de un diseño común a nivel de sistema y la maximización de la libertad de elección de diseño a nivel de API individual. La elección entre integración centralizada para lograr consistencia y optimización y descentralización para flexibilidad y desarrollo es un problema común en un sistema complejo.
- La integración centralizada nos ha traído la típica arquitectura de TI empresarial del pasado. La principal fuerza impulsora fue la estandarización de la ejecución de funciones para proporcionarlas de manera óptima y con un costo mínimo. Un alto nivel de integración realmente simplifica la optimización, pero al mismo tiempo afecta la capacidad de realizar cambios y desarrollar el sistema final.
- La descentralización es lo contrario. El ejemplo más accesible y a gran escala es Internet. La principal fuerza impulsora aquí es la estandarización del acceso a las funciones para que pueda proporcionarlas de muchas maneras diferentes que evolucionan constantemente. Al mismo tiempo, las funciones permanecen disponibles, ya que el acceso se basa en acuerdos generales sobre la interacción de las funciones. El objetivo principal de la descentralización es debilitar la coherencia ( http://bit.ly/2FpcUpf ), es decir, facilitar los cambios en partes individuales del sistema general sin la necesidad de cambiar otras partes.
DESCENTRALIZACIÓN Y EJECUCIÓN
Si hemos aprendido algo de las promesas incompletas del tiempo de una arquitectura orientada a servicios basada en SOAP, entonces la ejecución cuidadosamente administrada es un aspecto clave para implementar perspectivas orientadas a servicios. SOAP cumplió la promesa de proporcionar acceso a las funciones, pero no hizo frente a la tarea igualmente importante de administrar adecuadamente la ejecución de las funciones. Por lo tanto, aunque SOAP fue útil (las funciones que antes no estaban disponibles aparecían como servicios), no satisfizo las necesidades de un entorno más flexible y en evolución.
La complejidad de administrar el sistema API es recordar este problema y evitar la trampa en la que ha caído SOAP. SOAP dijo que solo la disponibilidad de servicios es importante. Este fue un primer paso importante, pero no permitió hacer frente a la débil coherencia de las funciones. Las API y, si se enfoca especialmente en las técnicas de implementación y despliegue, los microservicios nos permiten repensar lo que es importante para los grandes sistemas de servicio y cómo crear sistemas que no caigan en la trampa de SOAP.
Principio de plataforma
Muchos hablan de plataformas, discuten APIs y objetivos comerciales principales. Sin embargo, pueden significar cosas completamente diferentes. Es importante recordar: si a nivel empresarial parece una buena idea crear algo como plataforma, esto no significa que así es como debe desarrollarse a nivel técnico.
A nivel empresarial, la plataforma proporciona algo sobre lo que construir algo, y no podemos profundizar más que esta redacción bastante vaga. A menudo, el atractivo del concepto de "plataforma" está influenciado por dos factores principales.
- ¿Cuál es la cobertura de la plataforma? Es decir, ¿a cuántos usuarios se puede llegar creando algo en esta plataforma? Esto generalmente está determinado por la cantidad de usuarios o suscriptores. A menudo, este es el parámetro más importante, calculado por el número total o mediante el uso de factores cualitativos que determinan los usuarios correctos, que se pueden cubrir con esta plataforma.
- ¿Qué características tiene esta plataforma? Si creas algo en él, ¿cómo te ayuda o te limita en términos de ingresos? ¿Y también es fácil cambiar la plataforma para agregar nuevas funciones, idealmente sin dañar a sus usuarios?
Estos parámetros son muy importantes para las empresas, pero hay un factor que a menudo se olvida: las plataformas siempre obligan a los usuarios a cumplir ciertas restricciones, pero lo hacen de diferentes maneras. Aquí hay algunos ejemplos.
- Las aplicaciones web pueden ser utilizadas por cualquier persona que cumpla con los estándares básicos de la red. En el caso más simple, este es un navegador moderno con soporte de scripting. Cualquiera puede crearlos y abrir el acceso a ellos, y cualquiera puede usarlos. No hay un elemento central que controle el funcionamiento de la plataforma web.
- Las aplicaciones en la App Store de Apple son similares en apariencia a las aplicaciones web, pero se proporcionan y usan de maneras completamente diferentes. Solo se pueden descargar de la App Store, por lo que Apple tiene el derecho exclusivo de decidir qué usuarios pueden instalar. Además, solo pueden ejecutarse en dispositivos iOS, es decir, Apple tiene el monopolio de la venta de dispositivos que son capaces de usar estas aplicaciones. Las aplicaciones en la App Store se crean específicamente para el entorno iOS, es decir, las inversiones en su creación están limitadas solo por esta plataforma. Para usar la aplicación en cualquier otra plataforma, incluida Internet, debe reproducirse en un entorno de desarrollo diferente e incluso en un lenguaje de programación diferente, lo que significa que el lado del cliente de la aplicación debe recrearse desde cero.
Puede aplicar esta plantilla tanto a los sistemas API como a la idea de crear una plataforma API para aplicaciones.
A veces, la plataforma API se refiere a un entorno específico que proporciona acceso a la API. Pronto, comienza a parecerse un poco al bus de servicio empresarial tradicional, donde una plataforma similar debería proporcionar la infraestructura, y las API se vuelven accesibles debido al hecho de que pueden usarlo.
En otros casos, cuando se habla de la plataforma API, se refieren a un conjunto común de principios utilizados y proporcionados por los servicios. En este caso, si el servicio se convierte en parte de la plataforma, no tiene nada que ver con dónde y cómo se le abre el acceso. Si los servicios se adhieren a los mismos principios, protocolos y plantillas, proporcionan API en esta plataforma y, por lo tanto, se convierten en parte del sistema API.
El segundo tipo de plataforma es más abstracto, pero al mismo tiempo tiene más funciones. Separando qué funciones realizan y cómo lo hacen, facilita la contribución de los usuarios a la plataforma. También abre muchos caminos para la innovación, permitiendo que las aplicaciones experimenten con métodos de implementación sin comprometer su capacidad de contribuir al sistema API.
Y de nuevo, tome Internet como ejemplo. Si observa solo desde el punto de vista de la API, permite que muchas cosas cambien con el tiempo. Por ejemplo, una red de entrega de contenido (CDN) no está integrada en Internet. Su existencia fue posible debido a la complejidad del contenido de Internet y la flexibilidad del navegador, que le permite generar páginas web basadas en varias fuentes tomadas, posiblemente de diferentes lugares. Se podría argumentar que el potencial para crear una CDN ya existía en los principios y protocolos de las primeras páginas web, pero la plantilla de CDN apareció solo cuando surgió.
Es esta capacidad de adaptarse a las nuevas tareas lo que se requiere en los sistemas API. Diseñamos un sistema basado en principios y protocolos abiertos y extensibles, pero podemos y queremos cambiarlo si es necesario. También estamos creando plantillas de soporte que ayudan a las aplicaciones a resolver problemas de manera más eficiente, y queremos desarrollar estas plantillas con el tiempo.
Principios, protocolos y plantillas
La conclusión principal de la sección anterior: la plataforma no debe requerir una forma específica de hacer algo (responda la pregunta "¿Cómo?") O un lugar específico (responda a la pregunta "¿Dónde?"). Se crea una buena plataforma para el desarrollo continuo de la arquitectura, es decir, la arquitectura de la plataforma (y no solo la arquitectura del producto) está en constante evolución, y no todo se desarrolla a la vez, por lo que permanece sin cambios todo el tiempo de su existencia.
DESARROLLO DE ARQUITECTURA CONTINUA
El desarrollo continuo de la arquitectura es una metodología para el desarrollo continuo de los fundamentos de la arquitectura del producto. Los productos individuales se crean utilizando marcos de arquitectura existentes, y los informes sobre la aplicación de estos marcos pueden mejorar la arquitectura del producto, haciéndolo más eficiente.
Una metodología de desarrollo flexible y DevOps están dedicados a mejorar el desarrollo de productos individuales. No hablan sobre cómo mejorar los conceptos básicos de este proceso para que una arquitectura de sistema más eficiente sea útil para la arquitectura del producto. El desarrollo continuo ocurre cuando se crean productos individuales en el entorno de trabajo de un sistema existente. El sistema facilita la creación de nuevos productos y ayudan a encontrar áreas de mejora, creando así un ciclo de retroalimentación.
El desarrollo continuo de la arquitectura se centra en el desarrollo de un marco que no dañe los productos existentes y permita la creación de combinaciones de productos. Idealmente, los conceptos básicos de la arquitectura evolucionan constantemente para ser compatibles con las versiones anteriores, por lo que el sistema casi no está roto.
Para que sea posible el desarrollo continuo de la arquitectura, la plataforma debe estar construida sobre principios, protocolos y plantillas. Podemos ilustrar este punto con una plataforma web. Hace tiempo que se sabe que Internet es increíblemente estable y flexible al mismo tiempo. En los últimos 30 años, su arquitectura básica no ha cambiado, pero, por supuesto, ha evolucionado notablemente. ¿Cómo se hizo posible esta clara contradicción? Después de todo, otros sistemas encuentran problemas mucho más rápido, moviéndose a lo largo de trayectorias menos radicales.
Una de las razones principales es que nada en Internet muestra cómo se implementa o activa un servicio en particular. Los servicios se pueden implementar en cualquier idioma y, por supuesto, cambian con los años, porque los lenguajes de programación también cambian. Se proporcionan utilizando cualquier entorno de trabajo: al principio eran los servidores ubicados en las bodegas, ahora ubicados en Internet, y recientemente también apareció el almacenamiento en la nube. Los servicios pueden ser utilizados por cualquier programa cliente; también han cambiado drásticamente de simples navegadores de línea de comandos a navegadores gráficos complejos en teléfonos móviles modernos. Centrándose únicamente en la interfaz, que determina cómo se reconoce, intercambia y demuestra la información, la arquitectura de Internet resultó estar mejor adaptada al crecimiento natural que cualquier sistema de TI complejo que hayamos visto. Las razones para esto son sorprendentemente simples.
- Los principios son conceptos fundamentales construidos sobre la base de la plataforma. En el caso de Internet, uno de estos principios es que los recursos son reconocidos por un identificador uniforme de recursos (URI), y luego el protocolo de reconocimiento de URI da permiso para interactuar con estos recursos. Por lo tanto, aunque podemos (al menos en teoría) ir a Internet sin HTTP (y en cierto sentido ya nos estamos moviendo porque los protocolos en todas partes están cambiando a HTTPS), es difícil imaginar que sea posible ir a Internet sin recursos. Los principios se reflejan en los estilos de la API, porque los estilos se basan en diferentes conceptos fundamentales.
- , . (Hypertext Transfer Protocol (HTTP)), (FTP) , WebSockets WebRTC. , , HTTP/2.
- — . , , , . — Oauth, HTTP, — . — . , Oauth, , CDN. , , , , . — , .
, . , , . , -, .
, . . , - , . , , . , , , .
API . , , , , , . API — , , .
API
API . , , . , «» API, , API, .
API .
- API (, / ) . , API RPC — , API REST .
- API . , API HTTP HTTP.
- API . , 200 HTTP ( http://webconcepts.info/concepts/http-header/ ), . API , , .
- API , API ( «» . 188). : API , API, .
, — . , — . , , . , .
API — , .
- , , , , . , .
- , , . , . , , .
. , , , .
« » - - , . XML/JSON. XML-, API JSON ( , , , ).
API API
API , , , API . , . , API! API API: «, API, API».
, , API API (, , API). API API. API ( — «» « API» ), API . , .
, , , , . , API API.
, API API , . , .
. , API . , , - API.
«», «», «» «» . , , . , - , . , . , , , , , . « API» « API» 9 .
, API, API, API .
API , — , . . . — , .
, : , API, API. , , , , , , , API API, API API. API , , .
. , API, , , . , -, .
API API, , , , -. , : , API , , , , .
, API , : API , . : , , API, , .
— API, OAuth.io APIDays — API, . API API, , , API - . API, «API : », 2015 API « ». , - HEC API.
, API . IETF W3C. , , EMC, Siemens CA Technologies.
. API UX , API .
, , , , - . API API , , , API .
»
»
»
25% —
APIe-mail .