En un contexto arquitectónico o de diseño de sistemas, la administración de API se refiere comúnmente a un proxy inverso configurable y de gran funcionalidad que se utiliza para administrar el acceso de los clientes (externos, internos o de otro tipo) a una API, un extremo o un método. Comúnmente utilizada con las API RESTful, aunque no exclusivamente, la administración de API proporciona una capa de administración y protección de las solicitudes para que una solicitud entrante pueda ser verificada, inspeccionada, modificada y se pueda actuar en consecuencia, y la respuesta que llega de vuelta del sistema backend pueda ser modificada o se pueda actuar en consecuencia. Algunas organizaciones pueden utilizar un bus de servicios empresariales para lograr objetivos similares. Un bus de servicios empresariales es un término definido de manera flexible para una clase de tecnologías que incluyen implicaciones adicionales relacionadas con ese componente, pero que pueden beneficiarse del mismo conjunto de recomendaciones para los servicios de administración de API.
A continuación, se mencionan algunos ejemplos de sistemas de administración de API:
El comportamiento de administración de la API es diferente al de un proxy inverso tradicional, que normalmente reenvía un patrón completo de tráfico HTTP a un servidor backend. Por ejemplo:
<host-externo>:443/server/rest/services/* » <host-interno>>:6443/arcgis/rest/services/*
La administración de API a menudo implica la selección de rutas URI de API y métodos HTTP individuales (es decir, un POST a /routes/extract y un PATCH a /routes/<routeid>), lo que significa que hay que definir cada método o patrón individual, pero también que cada patrón puede tener reglas, comportamientos y agentes de escucha o servicios backend diferentes. Se utiliza con frecuencia en la construcción de nuevas API o sistemas, cuando no existe un conjunto de servicios web, o para habilitar una arquitectura al estilo de los microservicios, en la que otros componentes o sistemas backend se encargan de dar servicio a solicitudes de API independientes. En algunos casos, la administración de API puede utilizar una definición de API de backend, como una especificación OpenAPI, para crear muchos extremos o métodos de frontend.
La administración de API también suele incluir una matriz de otras opciones de procesamiento, que o bien manipulan el contenido de la solicitud (ajustando o reescribiendo una ruta, agregando o modificando un encabezado, cambiando el destino en función del contenido del cuerpo de POST), aplican algún tipo de filtrado a la solicitud (limitación de velocidad, bloqueo de determinados rangos de IP, exigencia de claves de API), u operan sobre la respuesta (ofuscando nombres de servidores, eliminando encabezados de respuesta, agregando una huella digital o un identificador). Estas operaciones se definen en la capa de administración de API y se ejecutan en cada solicitud a medida que se envía y se crea una respuesta.
Todos estos patrones se aplican generalmente también a las tecnologías de bus de servicios empresariales, con algunas diferencias. Los ESB tienden a centrarse en la entrega sincrónica de mensajes, donde un cambio en una parte del sistema (se agrega un nuevo registro, se lleva a cabo una actualización) desencadena un envío de este cambio al ESB, que luego transforma y envía el mensaje a otros sistemas para mantenerlos sincronizados. En cierto sentido, la administración de API es más una metodología de consulta y sondeo, mientras que los ESB suelen introducir compromisos sólidos de entrega de mensajes, patrones pub-sub u otros planteamientos similares.
La administración de API se puede utilizar en muchos patrones diferentes con ArcGIS. En general, la administración de API es más aplicable a los casos de uso en los que se implementa «delante» de los servicios basados en ArcGIS Server, como los servicios de mapas, entidades o geoprocesamiento, en escenarios en los que dichos servicios deben exponerse a otro sistema empresarial o a un desarrollador o cliente final que utilice una aplicación personalizada. Algunas consideraciones clave para trabajar con la administración de API incluyen:
Por ejemplo:
/arcgis/rest/services/ServiceName/MapServer/arcgis/rest/services/ServiceName/MapServer/exportImage/arcgis/rest/services/ServiceName/MapServer/0/query/arcgis/rest/services/ServiceName/MapServer/1/queryLa administración de API es una forma cada vez más popular de proporcionar opciones de integración entre sistemas empresariales. Muchas organizaciones invierten en políticas o las crean para garantizar que todas las transacciones internas sean gestionadas por un sistema de administración de API, o pueden requerir el uso de la administración de API para crear servicios accesibles desde el exterior. En el contexto de la integración de sistemas, las prácticas recomendadas incluyen:
La administración de API no incluye por definición una capa de autenticación, pero muchas organizaciones desean aplicar la autenticación a los extremos de su administración de API, con fines de validación de usuarios y administración de autorizaciones. Los métodos comunes de autenticación para la administración de API incluyen el uso de una clave de API o de suscripción, así como la integración con métodos de autenticación basados en OAuth a un proveedor de identidad (IdP) existente. Cada uno de estos patrones puede crear algunos retos con los flujos de trabajo de integración de ArcGIS.
Tenga en cuenta que los métodos de autenticación de clientes basados en la administración de API pueden no ser compatibles con los clientes estándar de ArcGIS. Por ejemplo, si el sistema de administración de API exige una autenticación basada en encabezados, ya sea utilizando un encabezado específico del servicio o un encabezado de autorización de portador, los clientes estándar de ArcGIS no podrán agregar ese encabezado dinámicamente a las solicitudes para admitir el acceso a ese servicio. Del mismo modo, las claves de API podrían ser una capa de autenticación común que se agrega a través de una interfaz de administración de API, pero los desarrolladores de aplicaciones deben ser conscientes de este requisito y tener la capacidad de agregarlo a las solicitudes para integrar estos servicios en una aplicación. Diversos SDK de ArcGIS y patrones de registro de servicios pueden admitir este tipo de patrón de autenticación de clave de suscripción o clave de API, pero deben probarse cuidadosamente antes de asumir que un patrón de autenticación es adecuado.
La autenticación basada en OAuth para la administración de API presenta otros retos. Al desarrollar una aplicación personalizada con un SDK compatible, puede resultar relativamente sencillo proporcionar un redireccionamiento inicial al servicio OAuth, devolver un token o código y utilizar ese token para incorporarlo a futuras solicitudes en esa sesión. Sin embargo, al utilizar la aplicación ArcGIS lista para usar, esta configuración es mucho más difícil de utilizar correctamente, ya que estos clientes esperan acceder directamente a los geoservicios de ArcGIS, sin pasos de autenticación adicionales que no sean gestionados por ArcGIS.
Por lo general, el uso de claves API o de suscripción proporciona la ruta de integración más exitosa en este contexto, con las siguientes recomendaciones: