Header Ads Widget

Ticker

6/recent/ticker-posts

5 razones por las que los desarrolladores no utilizan su API

 

2246383366_bd18fb6259_z

¿Ha lanzado su API y tiene dificultades para comprender por qué no se utiliza tanto como esperaba? Ha seguido todas las mejores prácticas, ha utilizado las últimas tecnologías y se ha asegurado de que esté siempre en funcionamiento. Por alguna razón, los desarrolladores no están usando su API y su uso no aumenta con el tiempo.

Quizás te olvidaste de lo más importante de tu API: ¡los desarrolladores! Sin desarrolladores que utilicen su API y creen nuevas aplicaciones, todo el esfuerzo que ha realizado no tiene sentido. La pregunta que debería hacerse ahora es ¿ por qué los desarrolladores no utilizan más su API ? Siga leyendo para obtener algunas respuestas posibles.

1. Dificultades para registrarse

Comencemos analizando cómo los desarrolladores pueden comenzar a usar su API después de enterarse. ¿Cuánto tardan en empezar? Ori Pekelman , un orador habitual en eventos de API, creó una regla que resume el mejor compromiso posible entre los desarrolladores y su API. La regla 3: 30: 3 establece que en la página de inicio de su API, un desarrollador debe:

  1. Comprenda en 3 segundos el propósito de su API.
  2. Ser capaz de identificar el punto de entrada en 30 segundos .
  3. Sea capaz de crear una cuenta, llamar al sistema y utilizar el resultado en menos de 3 minutos .

Para poder seguir esta regla, debe tratar su API como un producto donde los desarrolladores son sus clientes objetivo. Primero, céntrese en la página de inicio en sí y en el mensaje que transmite a los visitantes. Los desarrolladores deben comprender rápidamente la característica principal que ofrece su API y cómo pueden comenzar a usarla.

El proceso de registro debería ser lo más sencillo posible, pero debería poder obtener toda la información que necesita durante esta fase. Una buena estrategia es permitir que los desarrolladores se registren utilizando un servicio de terceros popular como GitHub. Debido a que GitHub usa un estándar de autenticación abierto llamado OAuth , es fácil agregar un botón "Registrarse con GitHub" a su portal de API. Podrá capturar rápidamente el nombre del desarrollador y la dirección de correo electrónico sin que tengan que escribir nada.

Una vez que los desarrolladores se hayan registrado, debe dejar que prueben su API lo antes posible.

2. No hay zona de pruebas para jugar

Una excelente manera de permitir que los desarrolladores prueben su API sin tener que crear una cuenta real es proporcionar una caja de arena que imite todas las funciones sin manipular ninguna información real. La caja de arena debe ser fácil de implementar y restablecer por parte del desarrollador cuando sea necesario.

Los desarrolladores usarán la caja de arena como lo harían con su API de producción. La principal diferencia es que, por lo general, el punto final de la zona de pruebas tendrá su propia URL. El objetivo aquí es permitir que los desarrolladores realicen pruebas en la zona de pruebas y migren rápidamente cuando sientan que están listos para pasar a la producción.

Una buena opción para proporcionar una caja de arena es utilizar algún tipo de virtualización que le permita a su sistema implementar rápidamente un servidor que esté listo para ser utilizado por los desarrolladores. Hay varias opciones disponibles con distintos niveles de complejidad:

  • Usando Vagrant con una imagen que contiene su servidor API y un conjunto de datos falso. Vagrant lanza rápidamente una máquina VirtualBox que puede apagarse y reiniciarse fácilmente.
  • Uso de Vagrant con un proveedor de alojamiento en la nube como DigitalOcean . Esta opción lo hará aún más fácil porque no tiene que lidiar con los servidores usted mismo. Hay un gran tutorial que explica cómo configurar y ejecutar esta configuración.
  • Usar Docker para lanzar rápidamente un nuevo entorno de API al que los desarrolladores pueden acceder. Una forma de hacer esto es usar Fig, que le permite lanzar un entorno aislado usando Docker.

Elija la opción que mejor se adapte a sus necesidades, pero recuerde que la zona de pruebas es solo un entorno temporal donde los desarrolladores pueden experimentar con la API. Debería rellenar previamente las bases de datos con un conjunto de datos completo y ofrecer una forma rápida y sencilla de restablecer la zona de pruebas cuando sea necesario.

La API de Google Adwords sigue este enfoque, ya que permiten a los desarrolladores realizar llamadas a la API en un entorno de prueba . Namecheap también ofrece un entorno de zona de pruebas y alienta a los desarrolladores a usarlo antes de realizar llamadas contra su API de producción.

3. Documentación deficiente o inexistente

Una API de espacio aislado es tan buena como su documentación. Una buena forma de empezar es ofrecer un recorrido por las funciones de la API con código de muestra que los desarrolladores pueden probar rápidamente en la zona de pruebas y ver los resultados.

También debe ofrecer una referencia API completa que describa todos los métodos existentes, sus parámetros y respuestas. Preste especial atención a los formatos de entrada y salida (JSON, XML, etc.) y proporcione ejemplos siempre que sea posible.

Hay dos secciones de documentación en las que debe tener más cuidado porque están relacionadas con la forma en que los usuarios finales de aplicaciones de terceros interactuarán con su API y cómo su percepción podría verse afectada:

  • Autorización : si permite que los consumidores de API actúen en nombre de los usuarios, debe proporcionar documentación concisa que explique exactamente cómo funciona la autorización y qué opciones están disponibles para los desarrolladores.
  • Términos y condiciones : debe describir claramente lo que permite que los desarrolladores hagan con su API y cuáles son sus responsabilidades para con los usuarios finales. Ese artículo cubre la mayoría de las opciones disponibles para licenciar su API, incluso si no tiene recursos para contratar a un abogado.

Si su API ofrece cualquier otra característica que considere importante, definitivamente debe proporcionar una sección de documentación dedicada y separada. Cuanto más enseñe a los desarrolladores, mejor comprenderán lo que pueden hacer con su API. Agregar ejemplos de código para todas las llamadas, por ejemplo, puede ayudar a los desarrolladores a comprender mejor cómo se puede usar la API.

4. Falta de recursos para solucionar problemas

Después de la documentación, la resolución de problemas es el aspecto más importante del que debe preocuparse. Más a menudo de lo deseado, una API se comporta de una manera que el desarrollador no esperaba, y debería ser fácil comprender lo que realmente sucedió. Debe proporcionar una consola donde los desarrolladores puedan inspeccionar todas las llamadas realizadas a la API, sus entradas y respuestas. Con esta información, podrán identificar lo que está sucediendo detrás de escena.

Aún mejor es si también mantiene un foro o una forma de permitir que los desarrolladores se comuniquen rápidamente con usted y discutan los problemas que ocurren con las llamadas a la API. Si trata su API como un producto, como sugerí anteriormente, puede que le resulte más interesante ofrecer un canal de soporte utilizando un servicio como Zendesk o GetSatisfaction . Estos le permitirán hacer públicas las solicitudes de soporte, lo que dará como resultado una base de conocimientos de fuentes múltiples.

Como beneficio adicional, también puede ofrecer una página de estado que describa cómo se están desempeñando los diferentes componentes de su API a lo largo del tiempo. Esto facilitará la depuración de posibles problemas relacionados con la conectividad y evitará pérdidas de tiempo. Stashboard es un interesante proyecto de código abierto creado por Twilio que te permitirá hacer esto de una manera fácil y efectiva. Si no desea instalar nada, puede utilizar una herramienta SaaS. Pingdom ofrece un servicio de tablero de estado y monitoreo que se puede configurar fácilmente.

5. Mala comunicación

Si bien es importante poder responder a posibles solicitudes de soporte, también debe prestar especial atención a cualquier comunicación saliente. Los desarrolladores valoran las empresas que se comunican abiertamente sobre cualquier cambio, problema o mejora de la API.

Debe comunicarse siempre que ocurra cualquier evento interesante que afecte el uso de la API de alguna manera. Los ejemplos incluyen lanzamientos de nuevas funciones (con cambios de documentación adjuntos), cambios de estado de API donde uno o más componentes dejan de estar disponibles o son lentos, cambios en los términos de servicio y también cualquier aplicación nueva de terceros que se haya lanzado.

Se pueden utilizar varios canales de comunicación: una lista de correo centrada en el desarrollador con una dirección de respuesta supervisada por el equipo de soporte, un blog especializado con un feed RSS que funcione y comentarios abiertos, y cualquier otra plataforma popular de redes sociales (por ejemplo, Twitter). No usar las redes sociales, una lista de correo y tu blog es un gran error que no querrás cometer . Debe comprender a su audiencia de desarrolladores y utilizar los canales más adecuados.

Conclusión

A estas alturas, debe saber que los desarrolladores son, de hecho, lo más importante de su API. Si trata su API como un producto y los desarrolladores como sus clientes objetivo, podrá ofrecerles una mejor experiencia. Tu API es un reflejo del producto que estás vendiendo. Si no ha alcanzado el ajuste producto / mercado, será mejor que comience a pensar en cambiar o repensar su estrategia. Una API por sí sola no podrá cambiar lo que es su producto y su calidad.

Comience mejorando su proceso de registro de API que debe simplificar al máximo. La documentación es un factor importante para una buena experiencia de desarrollador porque es lo primero que buscan los desarrolladores cuando quieren comenzar a usar una API. Para permitirles que prueben su API, puede seguir un enfoque de espacio aislado en el que es fácil implementar y restablecer un entorno de prueba de API completo. En caso de que algo salga mal, debería haber herramientas de resolución de problemas disponibles y posiblemente una placa de estado de API. Recuerde siempre comunicar cualquier cambio o evento interesante a la comunidad de desarrolladores para mantenerlos al tanto.

¿Se te ocurre alguna otra forma de mejorar la experiencia del desarrollador? ¡Deje un comentario aquí o póngase en contacto para discutir esto más!

Publicar un comentario

0 Comentarios