Header Ads Widget

Ticker

6/recent/ticker-posts

7 lecciones importantes de diseño de API



Ahora que el Tour mundial de las API nórdicas ha finalizado, regresemos para resumir lo que aprendimos. Durante nuestro recorrido, los practicantes expertos de API compartieron sus conocimientos con los asistentes en 4 ciudades, abordando el desarrollo de API, la seguridad, el diseño, las operaciones y más durante la configuración de la conferencia íntima.

Un tema recurrente en muchas charlas fue el diseño de API . Entonces, en este artículo, resumiremos lecciones importantes de diseño de API que fueron transmitidas por nuestros oradores, tanto consejos prácticos sobre implementación técnica como consideraciones más filosóficas sobre cómo ocultar (o no ocultar) la complejidad al diseñar una API. .

1: Conozca los requisitos de su API

El diseño de la API no debe comenzar con la documentación técnica, sino que debe tener su origen en sus objetivos fundamentales. Saber lo que su API necesita para lograr es de suma importancia. Esto se define en la fase de análisis del ciclo de vida de la API .

Como señaló Phillipp Schöne de Axway , los diseñadores de API deberían preguntarse " cómo las API pueden respaldar la función empresarial y no cómo pueden respaldar las necesidades de TI ".

2: Piense en las API como bloques de creación

Es importante recordar las características únicas de las API. Como consumidor, vincularse a la funcionalidad o los datos subyacentes de un servicio es inherentemente un proceso único. Aunque es comparable a los productos SaaS, Andreas Krohn de Dopter destaca dos diferencias clave:

La primera es que las API son bloques de construcción y no productos terminados: " Si alguien está usando su API, básicamente le está subcontratando una parte de su negocio ".

Su segunda lección es que las máquinas no son flexibles . Si un producto SaaS cambia, una persona puede adaptarse, pero si cambia una API, una máquina no es tan adaptable. Esto influye en el diseño y en todo el ciclo de vida de la API, y afecta la forma en que nos preparamos para los cambios de parámetros y el control de versiones.

Vea la charla de Andreas Krohn: Introducción al ciclo de vida de la API

3: comprende a tu audiencia

Los desarrolladores son consumidores únicos en el sentido de que vienen con un puñado de consideraciones específicas. Durante su charla, Bill Doerrfeld recomienda a los anfitriones de API que traten su plataforma como un producto, con una preocupación principal de ensamblar un análisis demográfico completo. Saber quién es su desarrollador objetivo puede refinar la funcionalidad de la API y segmentar futuros intentos de marketing.

La necesidad de comprender a su audiencia es igualmente aplicable durante la etapa de operaciones de una API. Si está actualizando, versionando o realizando rediseños importantes en una API existente, debe responder cuidadosamente a los comentarios de sus usuarios para que la nueva versión sea lo mejor posible.

Marjukka Niinioja , consultora senior y gerente de PlanMill comparte su experiencia aprovechando los comentarios de los usuarios durante un rediseño importante: el desarrollo de la nueva API RESTful , la interfaz de usuario y la arquitectura back-end de PlanMill .

PlanMill prestó mucha atención a la retroalimentación que estaban recibiendo internamente, notando tres puntos principales recurrentes:

  1. La API era demasiado compleja para que la usaran los desarrolladores.
  2. La documentación no fue suficiente.
  3. El manejo de errores necesitaba trabajo.

Utilizando estos comentarios y probando y consumiendo la API ellos mismos, el equipo de PlanMill pudo concentrarse en aspectos importantes a considerar durante la redistribución. La conclusión es que si está rediseñando una API, está preparado para lanzar mejoras impresionantes de la API, ya que ya tiene datos del mundo real sobre cómo se usa la funcionalidad de la API , que se pueden reutilizar para mejorar la eficiencia y la experiencia general del usuario de la API.

Vea la charla de Marjukka Niinioja: APIfying an ERP

4: Disminuya la confusión del usuario, deje que el proveedor maneje la complejidad

¿Quién paga el precio de la complejidad? El veterano de las API nórdicas, Ronnie Mitra, de API Academy, sostiene que la complejidad es necesaria; lo que debería evitarse es la confusión. Mitra sostiene que " es un trabajo de los diseñadores reducir la confusión y adoptar la complejidad en su dominio empresarial ".

Ha habido un movimiento hacia productos más simples y diseños de interfaz más simples. Mitra, experto en experiencia de desarrollador y diseño de API, aboga por software y API diseñados de forma inteligente que conserven la simplicidad pero que también satisfagan requisitos complejos. Citando las leyes de la simplicidad de John Maeda, Mitra señala que "la simplicidad consiste en restar lo obvio y agregar lo significativo ".

Mira la charla de Ronnie Mitra: A Simpler Time

Un volante en un coche de F1 es muy complejo en comparación con el volante de un coche normal, " diseñado y optimizado para su usuario y la situación ". Ronnie hace un gran punto de que " cada decisión de diseño es una decisión de si usted [como proveedor de API] o los desarrolladores de aplicaciones cliente pagarán el precio de la complejidad ". Por ejemplo, OAuth es complejo de implementar por el proveedor de servicios, pero fácil de usar por el desarrollador del cliente. No podemos evitar la complejidad, pero podemos diseñar nuestras API para que el lado del usuario sea engañosamente simple.

Ross Garrett de Axway también habla sobre lo que significa aplicar una estrategia de API primero para las organizaciones empresariales. Al tratar con sistemas heredados, señala que una confusión de infraestructura enredada se puede enmascarar mediante el uso de tácticas adecuadas de administración de API.

“Su antigua arquitectura [puede no tener] API útiles, o pueden ser servicios SOAP más antiguos que no funcionan bien en el contexto de la movilidad o la integración en la nube. Algunas cosas heredadas deben permanecer, pero la administración de API puede extenderse y reutilizarse traduciendo todas las interfaces antiguas "

Lo importante es tener una apariencia empresarial limpia para el usuario final.

Vea la charla de Ross Garrett: Entrega de API primero: ¿Es su API un ciudadano de primera clase?

5: Utilice Hypermedia para la evolución

Es imposible hablar de diseño de API sin mencionar Hypermedia, un tema que surgió en varias presentaciones durante el Nordic APIs World Tour 2015 . Pedro Felix del Instituto Politécnico de Lisboa , ofrece una inmersión profunda en HTTP. Él resume su presentación sobre el diseño de API de esta manera:

"si tiene un problema, mantenga la calma y busque una RFC HTTP "

Pedro considera que los hipermedia son el factor clave para la evolución, lo que permite a los proveedores de API reaccionar a los nuevos requisitos comerciales rápidamente sin romper las aplicaciones del cliente. En relación con la teoría de Mitra sobre la distribución de la complejidad, el uso de hipermedia significa más complejidad inicial para los desarrolladores de aplicaciones cliente, pero una complejidad general reducida considerando la facilidad de cambios futuros.

6: Aprenda del diseño de información del mundo real

Brian Mulloy de Apigee hace una demostración de una API de hipermedia para Internet de las cosas . Al utilizar hipermedia, es fácil introducir nuevos dispositivos en el IoT, ya que todos los estados, acciones y feeds posibles se describen en la propia API.

Mulloy describe el diseño de API para Internet de las cosas como el uso de diseño de información para objetos físicos. Lo comparó con los primeros días de la producción masiva de automóviles en su ciudad natal, Detroit. De repente, la ciudad tenía muchos automóviles, pero la infraestructura no estaba preparada para una gran afluencia de automóviles. La confusión resultante conduce al caos e incluso a un gran número de muertes relacionadas con el tráfico.

La solución fue utilizar un diseño de información que dio como resultado diseños estándar que se utilizan en todo el mundo en la actualidad. Los cruces de peatones, los semáforos, las señales de alto y los marcadores de carril dejan claro cómo comportarse en el tráfico. Al igual que en los primeros días de los automóviles, todavía estamos trabajando en cómo organizar y diseñar las API actuales para IoT.

Mira la charla de Brian Mulloy: necesitas una API para ese gadget

7: El diseño de API debe convencer al arquitecto

Tener una visión compartida dentro de una organización es clave para que se acepte la interconectividad de API. Para ayudar a convencer a los detractores de API, ya sean arquitectos o ingenieros, en su charla , Adam Duvander de Orchestrate explica cuatro formas en que los proveedores de API pueden enmarcar su producto API para fomentar una adopción segura. Estos factores deben tenerse en cuenta al diseñar una API para responder al estigma común asociado con las integraciones de API.

  1. El arquitecto quiere control : acostumbrado a los métodos tradicionales de infraestructura (almacenamiento de datos en servidores locales), el arquitecto puede oponerse a las operaciones en la nube y desea "tocar" el software. Para solucionar este estigma, los proveedores de API pueden ofrecer la capacidad de descargar y almacenar conjuntos de datos localmente, o incluso ofrecer una opción administrada, dedicada y local, la API.
  2. El arquitecto quiere cero tiempo de inactividad : para fomentar la confiabilidad en el servicio, es fundamental contar con registros transparentes orientados al desarrollador que comuniquen el tiempo de actividad de la API. Ejemplos de calidad son el estado del sistema Stripe y la transmisión en vivo de Twitter , que permiten actualizaciones de estado transparentes y útiles en el tiempo de inactividad. Otros para modelar son Facebook , Twilio y Github .
  3. El arquitecto quiere ver la responsabilidad : los sistemas API deben diseñarse como sistemas seguros utilizando enfoques modernos . Desde una perspectiva orientada al proceso, DuVander señala que los proveedores deben ser muy claros con los tipos de datos a los que pueden acceder. Comparta las mejores prácticas con los desarrolladores. Un buen modelo es Bit.ly : aclaran las licencias y comparten las mejores prácticas de seguridad en un canal dedicado .
  4. El arquitecto requiere una integración que garantice la longevidad : con las API públicas que se caen del mapa tanto de los jugadores pequeños como de los grandes, los arquitectos tienen una buena razón para ser escépticos. DuVander recomienda que los proveedores de API comprendan y comuniquen claramente su modelo de monetización y demuestren a los consumidores que su situación garantiza la longevidad. Según Duvander, cuando se trata de eso, " preocuparse por la longevidad de la API es solo otra forma de pedir más control "

Resumen de los puntos de diseño de API

Como una API tiene dos usuarios, el desarrollador humano y el cliente de la máquina , el diseño puede ser un poco complicado. Al analizar los comentarios de los desarrolladores, podemos diseñar mejores API para ellos y, al utilizar las técnicas adecuadas, podemos asegurarnos de que las API están diseñadas para un consumo eficiente de la máquina.

Al utilizar las lecciones aprendidas del Tour mundial de las API nórdicas, puede diseñar una API que permita a un proveedor de API manejar la mayor parte de la complejidad y simplificar los procesos para los desarrolladores de aplicaciones de sus clientes. Por encima de todo, no olvide que el diseño de la API debe satisfacer los requisitos generales de su negocio.

Publicar un comentario

0 Comentarios