Header Ads Widget

Ticker

6/recent/ticker-posts

Qué significa tener una API de espectro completo


 

Ampliando el alcance de su API

En desarrollo, el término pila completa (familiaridad con múltiples lenguajes de programación para el desarrollo tanto de frontend como de backend) se usa con bastante frecuencia. El espectro completo es el que se utiliza de vez en cuando y puede ser una mejor manera de describir las técnicas necesarias para una práctica de API superior.

Lo primero es lo primero, ¿qué es exactamente el desarrollo de espectro completo , especialmente en el contexto de las API web? No hay una definición dura y rápida, pero algunas piedras angulares incluyen:

  • Comprensión del desarrollo de front y back end en uno o más idiomas,
  • Conocimiento de DevOps, marketing, UX / UI y otras estrategias útiles,
  • Pensar profundamente cómo el producto / servicio encaja en el negocio en su conjunto.

Como puede ver, tener un espectro completo requiere un alcance mayor que la programación por sí sola; incluye usabilidad, negocios y marketing. Siendo este un blog de API, centrémonos en el desarrollo de espectro completo en lo que se refiere a las API.

API de espectro completo

Según Adam DuVander , que trabaja en marketing de desarrolladores en Zapier, la clave para crear una API de espectro completo radica en dos palabras:

  1. ¿Cómo? (¿La API es fácil de usar? ¿Para qué está diseñada?)
  2. ¿OMS? (¿La API es privada o pública? ¿Cómo es un usuario típico?)

Ahora, es fácil argumentar que abordar correctamente estas dos preguntas da como resultado una API que funciona correctamente y es bien recibida por los usuarios. En otras palabras, una API que es buena. Pero el proceso real de lograr una API de espectro completo requiere una reflexión adicional.

Si estamos hablando de API de espectro completo, es útil destacar algunas áreas en las que una API debe sobresalir para ser considerada una. En otras palabras, una API necesita hacer mucho más que funcionar según lo previsto para ser considerada de espectro completo.

En opinión de DuVander, convertirse en una API de espectro completo es una colorida unión de fortalezas complementarias. Vale la pena analizar cada uno de estos puntos a su vez, ya que cada uno amplía la idea de lo que se necesita para crear una API efectiva al observar los aspectos que están relacionados, pero que no necesariamente se refieren directamente a la tecnología involucrada.

Esta publicación acompaña a la presentación de Adam DuVander en la Cumbre de la Plataforma de APIs nórdicas de 2017. Mira aquí:

7 elementos de una API de espectro completo:

1: simple

“Nuestra experiencia con una API no es como se ven los documentos. Y no es (siempre) la documentación en sí ”, dice DuVander. Da el ejemplo de la documentación de Stripe, presentada sin ninguno de los elementos visuales y CSS asociados con ella, lo que implica que la documentación funcional no tiene que verse bien siempre que sea completa.

Idealmente, la documentación proporcionará ejemplos del mundo real y ofrecerá pasarelas para usar la API. Si los usuarios primerizos se rascan la cabeza y se preguntan "¿pero para qué puedo usar esto exactamente?" entonces probablemente haya algo mal con su documentación o con la propia API.

2: Productizado

Es muy fácil pensar en su API como algo divertido y fugaz, especialmente si no es realmente su oferta principal. Esa es una mentalidad que debe cambiar si desea llevar su API al siguiente nivel, y pensar en su API como un producto puede ser una forma útil de lograrlo. ¡Incluso si no planeas cobrar por ello!

Es posible que su API no termine tomando el mismo camino que Twilio , es decir, convirtiéndose en su oferta principal, pero eso no significa que no pueda convertirse en una herramienta útil en su arsenal empresarial.

3: impulsado por eventos

Piense en las mejores API que utiliza actualmente. Es muy probable que todos tengan al menos una cosa en común; el usuario realiza un desencadenante determinado , que da como resultado una acción . "No le sorprenderá que alguien de Zapier hable de esto", bromea DuVander, "porque todo nuestro producto se basa en esta idea de 'eventos'".

"Como gente de API, pensamos en nuestras API en términos de puntos finales, pero realmente quieres saber cómo alguien realmente va a usar lo que tienes". Usando un ejemplo de su experiencia en el trabajo, Adam habla de cómo los desarrolladores no tienen problemas para usar webhooks estáticos pero, según los datos de Zapier , los usuarios sí.

En lugar de trabajar desde una suposición pura, mirar los datos de uso es la forma más fácil de averiguar más sobre cómo y por qué la gente usa su API en el mundo real. Lo que nos lleva a ...

Relacionado: 5 protocolos para arquitecturas de API basadas en eventos

4: centrado en el cliente

Si crea una API exclusivamente para su propia gratificación personal, así es exactamente como se verá. Una posible excepción aquí es una API privada diseñada para mejorar las operaciones internas, pero aún así, en este caso, sus colegas son sus consumidores y sus necesidades deben ser satisfechas.

Las mejores API externas tienen éxito porque ahorran tiempo a los usuarios o les ayudan a lograr algo útil (o simplemente genial) que no pueden lograr solos. Siempre que esté creando o realizando cambios en su API, siempre mantenga la pregunta de cómo afectará esto a los usuarios. en mente.

Relacionado: El arte y la personalización de la experiencia de documentación de API

5: digno de confianza

Crear algo interesante y experimental es divertido. Es una de esas cosas que le entusiasma entrar en la oficina para poder empezar a trabajar. Sin embargo, el trabajo experimental es a menudo lo primero que se elimina cuando hay restricciones presupuestarias, cuando la empresa gira o cuando existe una necesidad real de centrarse en su oferta principal .

Netflix es un ejemplo de una API que se cerró por completo, y la de Twitter es una que, aunque sigue siendo pública, sufrió cambios que acabaron con varios servicios de terceros, así como las aplicaciones TweetDeck (propiedad de Twitter) para iOS y Android. Consulte las bajas de la API de Instagram para ver una historia similar.

DuVander utiliza la API de Tesco como ejemplo, que cree que es la única API que ha anunciado que mantendrá su servicio durante un mínimo de dos años . No tanto tiempo en el gran esquema de las cosas, pero demostrar tal compromiso de manera tan transparente es raro en este espacio.

6: accesible

DuVander explica que establecer compromisos a largo plazo para la disponibilidad "parece una expectativa realmente baja para una API, pero ¿cuántos de ustedes han tenido experiencia con una API que no funciona?" Como era de esperar, casi todas las manos de la sala se disparan.

El tiempo de actividad del 100%, o el tiempo de actividad del 99,99% , siempre será algo a lo que apuntar en lugar de una casilla que cada API pueda marcar. Por lo general, los usuarios no guardarán mucho rencor siempre y cuando destaque rápidamente los problemas , ofrezca información sobre cuánto tiempo de inactividad puede esperar y proporcione explicaciones de lo que salió mal.

Esto es algo que Slack hace muy bien y continúa disfrutando de un estado muy favorable con los usuarios a pesar de algunos incidentes solo en las últimas semanas.

7: utilizable

Como señala DuVander en su charla, usable es una palabra engañosa porque tiene más peso que solo poder acceder a algo. Utilizable significa “que, cuando algo anda mal, puedes obtener una respuesta o apoyo. Deje en claro dónde brinda apoyo y facilite la posibilidad de comunicarse ".

Eso podría ser a través de una cuenta de Twitter o exclusivamente por correo electrónico ; independientemente, es inteligente tener un canal de soporte para desarrolladores dedicado. Hacer que su API sea lo más autodescriptiva posible también puede aumentar la usabilidad y disminuir la compatibilidad 1–1.

En esa nota: 8 claves para hacer una API realmente utilizable

8: mantenido

Todos hemos estado allí: estás intentando usar una API, que crees que puede ayudarte a lograr algo realmente genial, y te diriges al sitio de la empresa para encontrar más información. ¿Su última actualización? Enero de 2009.

Tal vez haya encontrado accidentalmente el camino al centro de desarrolladores para una versión anterior de la API o tal vez la API simplemente ya no esté disponible; de ​​cualquier manera, el resultado es una falta total de información sobre a dónde ir a continuación.

Esto puede parecer un pequeño punto, pero los desarrolladores siempre aprecian la claridad . Tomemos, por ejemplo, esta breve publicación de MailChimp que anuncia su última versión de API y dónde encontrar documentación actualizada. Es posible que no pueda mantener todas las versiones de su API para siempre, pero SIEMPRE PUEDE mantener a los usuarios y usuarios potenciales informados sobre versiones y obsolescencias .

Pensamientos finales

Si aún no lo ha hecho, vuelva atrás y observe las letras de esas categorías nuevamente. Sí, deletrean ESPECTRO.

Anteriormente escribimos una charla de Adam que usaba el acrónimo PIE , por lo que deberíamos haber adivinado que volvería a hacer lo mismo. No lo hicimos, por cierto; nos llevó hasta el final de su charla ver lo que estaba haciendo.

SPECTRUM es un pequeño y divertido backronym con seguridad, pero es más que una palabra de moda. Una buena API es más que una simple pieza de tecnología; También es un producto orientado al cliente que debe ser simple, utilizable e inspirar confianza al ser accesible, estar bien mantenido y orientado a eventos.

La idea de una API de espectro completo genera varias formas de mejorar un servicio más allá de la funcionalidad básica. Es algo a lo que nosotros, como desarrolladores de API, deberíamos aspirar; ahora es algo que nos apasiona a todos

Publicar un comentario

0 Comentarios