Header Ads Widget

Ticker

6/recent/ticker-posts

3 pasos para preparar su API para el consumo

 


“Nos gusta pensar que somos una empresa de tecnología, pero comenzamos como una empresa de servicios”.

Así fue como Bo Li de ADP, un proveedor de software de nómina y recursos humanos con más de 740,000 clientes, abrió su discurso en nuestra Cumbre API 2019 en Austin . Se dice como un comentario casual, pero es un microcosmos de la línea que todas las empresas de API caminan: el equilibrio entre hacer cosas útiles con la tecnología y preparar adecuadamente esas cosas útiles para el consumo público .

Li es responsable de ADP Marketplace, que proporciona API que los desarrolladores pueden utilizar para integrarse con los sistemas ADP. Luego pueden crear soluciones y venderlas en la plataforma de ADP. Actualmente, Marketplace alberga 300 aplicaciones conectadas con un total de 800 proveedores en proceso de integración.

Su perspectiva es invaluable porque, al trabajar con cientos de desarrolladores de API, ha podido identificar un montón de problemas frecuentes que comparten. Algunos encuentran grandes obstáculos, pero, como veremos a continuación, también hay muchos más pequeños y menos obvios.

Vea a Bo Li hablar en la Cumbre de Austin de las API nórdicas de 2019:

 

Todo es tecnología (y negocios)

Crear una API interna , o una que esté diseñada para que la use un grupo muy pequeño de personas con las que está en contacto cercano, es muy diferente a preparar una que sea de acceso público y que utilice regularmente una gran cantidad de personas.

En el primer caso, es bastante fácil para los usuarios enviar un correo electrónico o llamar al desarrollador de API en cuestión, o incluso pasar por su escritorio en el camino de regreso de la máquina de café para preguntar cómo funciona algo. La mayoría de las API superan rápidamente esta fase, por lo que la documentación completa es tan importante.

Además, el tiempo de inactividad puede no ser un problema tan importante para las API que se utilizan internamente. Sin embargo, a medida que crece el apetito por una API en particular, también lo hace el riesgo muy real de que el tiempo de inactividad y otros problemas, por menores que parezcan, puedan afectar negativamente los negocios de los consumidores de esa API.

En ambas situaciones, la API se trata más como un proyecto favorito que como una rama legítima del negocio. Eso lleva a otro problema importante, a saber, la expectativa de que los consumidores de API se preocupen por su producto tanto como usted. Li explica que los desarrolladores de API a menudo "implementan en un mercado y luego, después de unos meses, dicen 'mmm, ¿por qué nadie presta atención a mi API?'"

Este problema es tan importante que Li ha intentado desarrollar un proceso para que los desarrolladores de API trabajen. Además de hacer preguntas útiles para ADP: “¿Cómo protege su API? ¿Cómo protege sus datos? ¿Qué tamaño tiene su carga útil? " - les pide a los usuarios que hagan la siguiente pregunta: “ ¿Qué problema resuelve su API? "

Solo cuando los desarrolladores de API piensan en su producto desde una perspectiva comercial  pueden comenzar a expresar por qué la API es digna de ser consumida. A continuación, hay otras tres formas en que puede hacer que su API sea digna de ser consumida.

1. La documentación es el rey

“Cuando los desarrolladores piensan en la documentación, piensan en Swagger, OpenAPI, etc., y eso es genial. Pero la especificación API y la documentación del producto son dos cosas muy diferentes ”, dice Li.

Cuando especificación y la documentación  se tratan como si fueran lo mismo, el resultado es una desconexión entre lo que prometen las especificaciones y lo que realmente ofrece el desarrollador de API. Para decirlo de otra manera, "la documentación de la API debe abordarlo todo ".

“Piense en el viaje de descubrir una API, evaluarla y luego determinar si satisface las necesidades de alguien y realmente usarla. En ese viaje están involucradas muchas personas diferentes ”, dice Li.

Li proporciona un ejemplo de cómo se puede evaluar la idoneidad de una API típica. En lugar de un desarrollador, el primer punto de contacto puede ser un empresario no técnico. Probablemente se preocupen menos por la carga útil y el tiempo de respuesta que por los datos que proporciona.

Aquellos que miran una API desde una perspectiva empresarial tendrán requisitos muy diferentes a los de alguien con una mentalidad más tecnológica o de un desarrollador que está pensando en intentar trabajar con la API en sí. Li sugiere que un gran portal para desarrolladores debería dirigirse a una audiencia más amplia que solo los desarrolladores. .

Portal de Apigee de Google es un buen ejemplo de esto, ya que comunica el valor de las experiencias de marca y cuantifica cómo el servicio aumenta la adopción de API además de los aspectos técnicos.

Relacionado: Cómo tratar su API como un producto

2. Creando una propuesta de valor

"No todas las API son iguales y no todas se están construyendo con el mismo propósito".

Suena bastante sencillo pero, como destaca Li, los desarrolladores de API no siempre tienen esto en cuenta cuando piensan en el valor de una API. Ella proporciona el siguiente ejemplo:

"Cuando se utiliza una API para igualar un producto o servicio ofrecido por un competidor, poner una cifra en dólares en la API [es decir, cobrar por ella] puede no ser la idea correcta".

Hay tres factores a considerar cuando se intenta calcular la propuesta de valor de una API:

  • Valor : ¿lo entrega a través de cada transacción? ¿Cómo se traduce en estrategia de precios?
  • Costo : considere tanto el costo operativo / de plataforma como el costo humano, por ejemplo, soporte, etc.
  • Términos comerciales : ¿se debe considerar alguna limitación de uso / volumen de llamadas o precios escalonados?

Habiendo hablado sobre la diferencia entre las personas que pueden estar evaluando la idoneidad de un API, Li revisa la idea de disparidad, esta vez centrándose en cómo se relaciona con aquellos que consumirán el API.

Sabemos que los diferentes consumidores tienen diferentes necesidades, pero es importante tener esto en mente para poder atenderlos como organización. Li proporciona ejemplos de aquellos que están construyendo API y Clientes internos versus externos (desarrolladores que usan API para construir sistemas para su propio uso) versus consumidores de proveedores (compañías de terceros que intentan construir una solución para vender a los clientes).

Dependiendo del consumidor objetivo, las diferentes situaciones requerirán diferentes términos comerciales, políticas, documentación, etc. Eso también, inevitablemente, tendrá un impacto en su estructura de precios. Es por eso que tantos productos tienen niveles personales, de pequeñas empresas y empresariales.

Más sobre API Docs: 5 ejemplos de excelente documentación de API (y por qué pensamos eso)

3. Participación organizacional

Ya hemos cubierto el hecho de que los compradores y los responsables de la toma de decisiones que buscan la idoneidad de una API pueden no ser desarrolladores. Como dice Li, “es posible que los equipos de TI les hayan dicho que, cuando estén validando una solución, 'se aseguren de tener API'”.

Habla de cómo los vendedores deben sentirse cómodos hablando de las API, así como de las ventajas que ofrecen, y cómo los equipos de soporte deben poder "hablar sobre las API, replicar problemas y comprender cuándo surge un problema en los datos que deben capturar para pasar esa información a un desarrollador ".

Para una empresa que crea una API, facilitar la aceptación organizacional significa:

  • Capturar la información necesaria para solucionar problemas
  • Identificar y asignar responsabilidad por problemas
  • Registro en todas las capas y estandarización de los mecanismos de registro, cuando sea posible, para brindar una imagen completa
  • Información más detallada sobre el manejo de excepciones, presentada de una manera fácil de usar

“Como parte de cualquier programa de implementación de API, necesitamos alinear [a los desarrolladores], al personal de marketing y de servicio. De lo contrario, toda la economía de las API no fluye ".

También destaca el componente de preparación organizativa en curso: "es importante preparar a los miembros del equipo cuando implementa una API por primera vez, pero también es importante prepararlos para cada paso del ciclo de vida".

En otras palabras, cosas como nuevas versiones y características deben informarse internamente. Eso es especialmente importante, dice Li, cuando ya hay personas que usan la API; ¿Cómo llegaremos a estos usuarios con novedades sobre la API y quién lo hará?

Pensamientos finales

En su tiempo trabajando con 300 desarrolladores de API, estamos bastante seguros de que, incluso si es demasiado educada para admitirlo, Bo Li se ha encontrado con muchos ejemplos de lo que no debe hacer al preparar una API para el consumo. Como resultado, tiene un montón de conocimientos sobre las mejores prácticas y recomendaciones para los desarrolladores que buscan lanzar una API.

En pocas palabras, estos se reducen a tres puntos clave:

  • El uso de una especificación de API no es suficiente cuando se trata de documentación eficaz
  • Considere lo que los diferentes grupos demográficos quieren saber cuando investigan su API
  • Sin la aceptación de la organización, una API está condenada al fracaso o al estancamiento

Por supuesto, hay más para crear una API exitosa que seguir solo este consejo. Pero, a menos que esté tomando en cuenta esta información a medida que avanza, es poco probable que llegue lo suficientemente lejos como para averiguar qué es.


Publicar un comentario

0 Comentarios