Header Ads Widget

Ticker

6/recent/ticker-posts

Consejos para enfoques internos de API-First


 El liderazgo intelectual de API normalmente se centra en la interacción externa. Esto tiene sentido para los productos API , y la mayor parte de la orientación en el espacio API es lo suficientemente general como para adaptarse a paradigmas tanto internos como externos. Incluso con un consejo más específico, la suposición es que la mayoría de los consumidores acceden a una API a través de un punto final externo, centrando la optimización en ese punto de fricción.

Debido a estas suposiciones, cosas como el famoso Mandato de Bezos se han convertido en una guía de facto para todo el espacio de la API, mientras que solo reflejan una parte de la imagen. ¿Qué sucede cuando sus consumidores son estrictamente usuarios internos? ¿Qué sucede cuando el patrón de consumo es completamente interno?

Hoy abordaremos los enfoques de API internas primero y daremos algunos consejos especialmente diseñados para las API enfocadas internamente.

Trate las API internas con cuidado

En primer lugar, debemos tener en cuenta que algunas cosas obviamente no cambian entre los tipos de API internos y externos. La experiencia del desarrollador siempre será increíblemente importante, independientemente de la fuente de ese usuario. El flujo de participación debe ser claro, fácil de entender y fácil de interactuar. La documentación debe ser sustancial y significativa, evitando cualquier tipo de flujo que obligue a los usuarios a investigar problemas comunes que se resuelven fácilmente. En esencia, no importa qué tipo de usuario esté siendo atendido, debe ser considerado el "cliente" y apoyado como tal.

Por supuesto, existen las mismas consideraciones de seguridad independientemente de la fuente del usuario. Se requieren esquemas de autorización y autenticación adecuados para garantizar que los sistemas estén a salvo de usos no deseados; este requisito no desaparece simplemente porque el usuario sea interno. Además, es esencial proteger dichos sistemas internos, donde es más probable que se otorgue al usuario una autorización más alta (más sobre esto en un momento).

Finalmente, la experiencia central debe ser respaldada como un producto para su utilización independientemente de quién la use. Existe una línea de pensamiento desafortunada entre algunos desarrolladores de productos que consideran que un usuario interno es diferente de uno externo; en otras palabras, entregan el "buen producto" al usuario externo y dependen del conocimiento del usuario interno para compensar el tiempo de desarrollo. en soluciones de interior. La realidad es que un usuario interno es tan importante y debe recibir una solución e implementación tan pulida y eficaz como el usuario externo.

¿Qué hace que una API interna sea diferente?

Dicho esto, los usuarios de API externos son notablemente diferentes de los internos. Los usuarios internos suelen ser un tipo diferente de usuario. Pueden tener necesidades más específicas y de mayor nivel de la API. Mientras que un usuario externo a menudo llega a un producto API para una sola función o propósito, y generalmente a través de un integrador de frontend, los usuarios internos a menudo buscan interactuar con la API en su totalidad para lograr transformaciones e interacciones más complejas.

Además, un usuario de API interno puede tener una mayor autorización que requiere una división más granular, mientras que las API externas generalmente separan la autorización aproximadamente en torno a diferentes niveles de usuarios. Los usuarios internos generalmente ya son propietarios de acceso elevado, divididos con mayor precisión por los grupos funcionales que pueden utilizar. Es menos exacto referirse a un usuario interno como perteneciente a un grupo como "administradores", y más exacto referirse a ellos como pertenecientes al "grupo de eliminación de contenido".

Sugerencias para API internas

Las API internas vienen con un conjunto particular de enfoques y sugerencias que pueden hacerlas más efectivas, escalables, extensibles y utilizables. Tenga en cuenta que cualquier cantidad de consejos y pautas no puede servir como reemplazo de un plan de API coherente; el hecho de que el producto sea interno no significa que no deba tratarse como un producto en sí mismo. Dicho esto, estos consejos contribuirán en gran medida a mejorar la experiencia interna del usuario desarrollador promedio.

Utilice guías de estilo internas

Las guías de estilo de API son quizás una de las mejores herramientas que una organización puede tener para el desarrollo de API internas (por no hablar del desarrollo de API en general, un tema que hemos discutido anteriormente aquí ). Una guía de estilo de API es un conjunto de pautas y principios que ayudan a los desarrolladores a diseñar su API en función de las funciones, los requisitos, el propósito comercial y el estilo general. En términos generales, esta guía se ubica en una línea entre dos polos opuestos: autoritario y autónomo.

Autoritario

Una guía de estilo autorizada es estricta y dicta una amplia variedad de funciones, espíritu de diseño, enfoques y más. Este estilo de orientación puede ser muy eficaz para las API internas que tocan datos regulados o sistemas internos esenciales; por ejemplo, los procesadores de pagos pueden tener que adherirse a estrictas regulaciones financieras y de pagos Como tal, las API internas creadas en torno a esta interacción de datos pueden necesitar pautas estrictas para garantizar el cumplimiento.

Una postura autoritaria también ayuda a las organizaciones en las que la API está estrechamente relacionada con un paradigma de diseño específico. Los escenarios de socios B2B pueden requerir un acoplamiento estrecho. En tales casos, una API interna también puede querer aplicar este acoplamiento internamente, proporcionando una experiencia unificada y sensata entre la API interna y el producto externo.

Autónomo

En el otro lado de este espectro está la pauta autónoma más laissez-faire. Esto es mucho más general y es más adecuado para experiencias poco acopladas. En este enfoque, las pautas son sugerencias de propósito general, en lugar de exigir el cumplimiento de un conjunto estricto de reglas.

Un autónomo es más adecuado para API internas que no son más que un conjunto de funciones, en lugar de una oferta cohesiva y unificada. Muchas organizaciones utilizan el desarrollo de API internas como incubación de productos y pruebas para nuevas formas y funciones. En este caso, una guía de estilo de desarrollo más autónoma es importante, ya que permite la más amplia variedad de opciones y libertad. Esto también es importante cuando se consideran las API internas para unidades funcionales individuales; puede ser cierto que una API de operaciones internas no necesita cumplir con las restricciones de estilo creadas para las API de recuperación de medios y, como tal, un conjunto más amplio de pautas podría ser mucho más apropiado .

Implementar sistemas de registro de datos

Las API internas a menudo tocan datos que no están disponibles para los usuarios externos; en parte, esa es la razón por la que deben mantenerse internos. Es fácil pensar que los usuarios internos que tocan recursos internos son confiables y, por lo tanto, no requieren el mismo seguimiento heurístico y seguridad de datos que las API públicas . La realidad es que los propietarios de API deben proteger todos los datos expuestos, independientemente de la persona que llama.

Como tal, la implementación de un sistema de registro de datos es vital. Los propietarios de API deben registrar cada transformación, cada servicio, cada manipulación de datos, etc., para garantizar la integridad de los datos. Esto está vinculado a la idea del control de versiones de la API , es decir, tener un sistema aparente que indique qué versión es la API o la fuente de datos y un sistema documentado para la gestión del ciclo de vida.

Tan importante como el proceso de integridad es el hecho de que estos sistemas de datos deben servir como una fuente singular de verdad. Si bien esto es importante en todos los enfoques de control de versiones, es primordial en términos de integridad de los registros de datos que solo debe haber una fuente de verdad para todos los registros de datos. En particular, esta fuente de verdad, si se utiliza para registros que se pueden manipular a través de sistemas externos e internos, debe sincronizar ambas interacciones para garantizar la integridad total de los datos.

Mantenga el tráfico interno

Como mencionamos anteriormente, las API internas pueden, en ocasiones, interactuar con datos y recursos que también son transformables a través de sistemas externos. Es tentador considerar las API internas y externas como dos caras de la misma moneda y tratarlas como tales. La realidad es que las API internas y las API externas están divididas por una pared sólida y deben considerarse mitades aisladas del mismo todo. El tráfico interno es distinto del tráfico externo.

Tomemos, por ejemplo, un sistema de gestión de clientes que utiliza una API externa para interactuar con los clientes, pero una interna para procesar los pagos. Puede resultar tentador simplemente crear una única API que tenga bloqueos de credenciales para funciones críticas. En este caso, lo que realmente ha creado es una API híbrida, una API dividida en dos casos de uso.

En realidad, si utiliza una API interna, debe esperar que una API shim transforme, traduzca y restrinja la transferencia de datos entre lo interno y lo externo, especialmente si se manejan datos de pago u otros datos protegidos. Una API interna ciertamente puede tocar los mismos datos que una API externa, pero este proceso debería ser la transferencia de datos de un dominio a otro, no el simple cambio de marca del mismo conjunto de datos en un contexto diferente.

Evite enrutar datos fuera de la API interna a menos que sea absolutamente necesario. Hasta ese punto, evite enviar datos externos internos a menos que también sea necesario. Los datos que son externos deben manejarse necesariamente de manera externa, y lo mismo ocurre con los datos internos.

Limitar el acceso por grupo funcional, no por rango de usuario

Si bien esta es una pauta de seguridad general, aquí se indica que no hacerlo internamente podría ser mucho más dañino que externamente. Al configurar el acceso a un recurso, llamada o función, asegúrese de que el acceso esté limitado por el grupo funcional; es decir, si el rol de un usuario es brindar soporte al cliente, restrinja su acceso a las funciones de soporte al cliente.

Limitar el acceso es especialmente importante para las API internas, ya que es más probable que las API internas tengan administradores de sistemas, entidades financieras y otras personas trabajando internamente. Un equipo de auditoría financiera puede solicitar un mayor acceso. Puede parecer prudente proporcionarles este acceso, pero ¿y si ese equipo es en realidad un equipo de seguridad que realiza pruebas de seguridad? ¿Qué pasa si un proveedor asociado en la API interna que puede necesitar acceder a un acceso limitado de cliente recibe acceso completo de cliente y luego se viola?

Este tipo de preocupaciones ya son problemas con las API externas, pero las API internas necesariamente tocarán datos más regulados y privados, donde el daño potencial es mucho mayor. Esto incluso puede ser necesario dadas las prácticas y políticas de seguridad API estrechamente acopladas cuando se alinean con las prácticas y procedimientos comerciales o del sistema.

El acceso rotatorio (es decir, limitar el acceso elevado a un solo rol o sistema a la vez), el seguimiento heurístico (monitorear la API interna para rastrear comportamientos fuera de lo común) y otros métodos utilizados para garantizar que las operaciones comerciales sean seguras pueden también se reflejan en sus prácticas API internas. Esto puede crear expectativas sobre cómo el acceso es limitado.

Documentar, educar y apoyar

La documentación es esencial independientemente de si una API es interna o externa. Es difícil pensar en sus colegas con los que ha trabajado durante meses desarrollando una API como usuarios desinformados, pero la realidad es que incluso sus colegas más ardientes no son perfectos. Estas personas no van a recordar los detalles sutiles de cada forma y función. Aunque sea un usuario interno, es posible que necesite la misma documentación, educación y soporte que un desarrollador externo.

La documentación, la educación y el soporte deben reflejar los de sus recursos externalizados, pero al nivel de complejidad y cobertura que requiere la base de usuarios internos. Si un administrador necesita conocer las funciones administrativas, esto debe cubrirse de manera integral, con un simple enlace, correo electrónico u otro recurso al que puedan seguir para obtener más información.

Al final del día, es difícil considerar a los usuarios internos como megausuarios que no comprenden de manera integral; sin embargo, este apoyo debe brindarse de manera adecuada y completa.

Conclusión

Aunque a menudo se combinan entre sí, las API internas son diferentes de las API externas. La realidad es que las expectativas, demandas y necesidades de una API interna requieren un enfoque matizado, o al menos una reconsideración de los supuestos. Con la mentalidad adecuada, el enfoque de desarrollo y las primeras consideraciones de la API interna, una API interna puede ser muy eficaz y segura.

¿Qué opinas de este consejo? ¿Estamos fuera de base? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios