Header Ads Widget

Ticker

6/recent/ticker-posts

Consejos para crear productos API aptos para desarrolladores



 “Los excelentes productos API no se crean por error”, dice Rahul Dighe , líder de productos API y de plataforma en PayPal. Incluso si tiene en cuenta todos los principios de tendencia de propiedad de la API (diseño primero, API como producto, gobernanza, KPI y más), es posible que termine con una API que es difícil de usar. Entonces, ¿qué consejo daría un estratega de productos API con más de diez años de experiencia?

En esta publicación, veremos los consejos clave de la charla de Rahul Dighe en la Cumbre de la Plataforma de 2019 . Estos cinco conocimientos deberían ayudarlo a crear API fáciles de usar para desarrolladores que resistirán la prueba del tiempo.

Vea a Rahul Dighe de PayPal hablar en la Cumbre de la Plataforma 2019 en Estocolmo:

1. Conozca a sus desarrolladores

No debería sorprender que la creación de productos API amigables para los desarrolladores comience con conocer a sus desarrolladores. Como experimento mental, Rahul presenta tres arquetipos de desarrolladores que podrían usar las API de PayPal. Incluyen un trabajador independiente que acaba de salir de la universidad; un experto en pagos, que ha estado en el espacio de pagos durante los últimos diez años; y un desarrollador desinteresado cuyos verdaderos intereses están en otra parte.

Cuando observe estos arquetipos, verá que todos los desarrolladores tienen diferentes niveles de inversión y experiencia. Sin mencionar que cada uno tiene su propio conjunto de requisitos, que dicta cómo interactúan con las API.

Como resultado, Rahul sugiere que considere los patrones de uso de sus arquetipos de desarrollador principal al crear nuevas API. Después de todo, las API son un medio para un fin y no el fin en sí. Es posible que algunos socios solo necesiten un widget único que no sea API para su integración, mientras que otros buscarán una solución API completa para migrar desde otro proveedor.

Un consejo particularmente útil que da Rahul es escribir un "un paginador", que contiene todas las entradas y salidas y los patrones de integración centrales que espera admitir con su API. Este documento actuará como un punto de referencia rápida durante el proceso de diseño de la API, lo que le permitirá asegurarse de que lo que está creando proporcionará la mejor experiencia a su audiencia de desarrolladores.

2. Sea obsesivo con los nombres

El siguiente consejo de Rahul fue la inspiración para mi artículo reciente, Más de 10 mejores prácticas para nombrar puntos finales de API . Él dice que debes ser "obsesivo" acerca de cómo nombras tus API. Después de todo, una vez que nombra una API, permanece allí durante bastante tiempo. Y aunque es posible que pueda evolucionar rápidamente, no hay garantía de que sus desarrolladores también lo hagan.

Si desea más detalles sobre cómo nombrar correctamente, asegúrese de consultar el artículo vinculado anteriormente. Si solo se pregunta por qué es importante nombrar, la respuesta es simple: puede que no parezca mucho. Aún así, el efecto de los nombres redundantes, inconsistentes o no descriptivos puede sumarse rápidamente, lo que dificulta el consumo de sus API.

3. Cíñete siempre a tu proceso

En este punto, muchas grandes empresas tienen un proceso probado para crear nuevas API, que incorpora mucho tiempo y diligencia debida. Comienza con una fase de descubrimiento, en la que presenta el problema que pretende resolver, a la que sigue una fase de diseño, en la que comienza a pensar en puntos finales concretos, campos, funciones de seguridad, herramientas, especificaciones e historias de usuarios. Luego, ingresa a una fase de desarrollo, antes de finalmente lanzar su nueva API.

Este proceso generalmente da como resultado grandes API intuitivas y completas. Sin embargo, Rahul recuerda haber entablado una discusión con un equipo de liderazgo corporativo sobre por qué tomó todo un mes agregar un campo a una API. Es fácil dejarse llevar por presiones externas como esta, pero Rahul cree firmemente que debes mantenerte firme.

Como diseñador de API, Rahul dice que está obligado a construir algo que se necesita hoy, pero que todavía se usará en cinco o seis años en el futuro. Puede pasar rápidamente por los procesos de descubrimiento, diseño, desarrollo e implementación, pero terminará con un producto que no es óptimo. En su lugar, manténgase en el enfoque que funcione y acepte que crear o actualizar una API llevará un poco más de lo que a otros les gustaría.

4. Construya un ecosistema completo

Si bien obtener una única API puede ser un desafío en sí mismo en algunos entornos comerciales, Rahul dice que las API son solo el comienzo y que no puede olvidarse del resto del ecosistema. En particular, destaca la importancia de los SDK, una caja de arena confiable y personal de soporte listo para depurar.

Rahul cree que estas pequeñas cosas sí importan. Por supuesto, se necesita tiempo para poner todas las piezas en su lugar, pero estos activos del ecosistema de soporte contribuyen significativamente a la usabilidad de sus productos API principales. Es importante destacar que realmente debe preocuparse por estos activos y mantenerlos: si no tiene cuidado, terminará con documentación vieja e inútil y una casilla marcada en algún lugar de la lista de verificación de API como producto.

5. Piense en la gobernanza de API

El último consejo de Rahul es pensar en cómo organiza y gobierna su conjunto de API. Llama la atención sobre la Ley de Conway , que sugiere que construimos sistemas que reflejan nuestras estructuras organizativas o de comunicación internas. El enfoque tradicional para combatir esto, es decir, construir API consistentes, a pesar de tener diferentes equipos trabajando en ellas, es utilizar algún tipo de sistema de gobierno de API. En teoría, al someter a todos los equipos de productos de API a los mismos estándares, las API deberían sentirse consistentes.

En la práctica, Rahul cree que siempre habrá pequeños matices entre las API creadas por diferentes equipos, lo que agrega complejidad para los desarrolladores que están integrando dos o más de ellas. Para combatir esto, Rahul sugiere usar algo similar a la maniobra Inverse Conway (explicada en el artículo anterior): si siempre va a tener dos productos API relacionados, haga que un solo equipo sea responsable de ambas interfaces de desarrollador. De esa forma, las API están destinadas a ser coherentes.

Pensamientos finales

Los mejores productos API se crean cuando haces las cosas correctamente. Eso comienza con saber quiénes son sus desarrolladores objetivo y cómo usarán su API. Más adelante, significa ceñirse a procesos y estándares de gobernanza de toda la organización que no se pueden negociar y han probado y probado, y obtener los nombres correctos a la primera. Finalmente, hay más en un ecosistema de API que solo la API en sí, y mantener activos de soporte como documentos, SDK y sandboxes es crucial.

Publicar un comentario

0 Comentarios