Header Ads Widget

Ticker

6/recent/ticker-posts

Diseño de API para humanos

 Uno de los temas más discutidos en la Cumbre de la Plataforma NordicAPIs de este año fue el Diseño de API y cómo puede afectar la forma en que se consumen las API. Las discusiones se centraron en cómo el diseño podría afectar la percepción de los usuarios finales de su producto. Varios oradores consideraron que este era un tema muy importante, y durante el evento se llevaron a cabo varias discusiones. Según Jason Harmon , director de diseño de API de PayPal, "las API están empezando a parecerse más al producto y menos a la tecnología". En otras palabras, API Design está empezando a parecerse cada vez más a la experiencia del usuario (UX) y menos a un simple mapeo técnico de la base de datos de su aplicación.

Honza Javorek , de Apiary, declaró claramente durante su charla que "los desarrolladores no se relacionan realmente con el enfoque de diseño de API de estilo de base de datos". Las API deben verse como una forma de proporcionar funcionalidad al usuario final; deben seguir las mismas reglas de usabilidad definidas por Peter Morville , mejor conocido como UX Honeycomb :

uxhoneycomb

Lecciones de UX

Para diseñar una API utilizando este nuevo enfoque, primero debe responder estas siete preguntas:

  1. Útil : ¿Es útil la API desde el punto de vista del usuario final?
  2. Utilizable : ¿Puede un desarrollador utilizar rápidamente la API y proporcionar una funcionalidad fácil de usar?
  3. Deseable : ¿Es la API y la funcionalidad que proporciona algo que genera deseo en desarrolladores y usuarios finales?
  4. Se puede encontrar : ¿Se puede encontrar fácilmente la documentación de la API y los desarrolladores pueden comenzar a usarla de inmediato?
  5. Accesible : ¿Puede la API proporcionar una funcionalidad que haga que las aplicaciones de terceros sean accesibles para personas con discapacidades?
  6. Creíble : ¿Los datos proporcionados por la API son confiables?
  7. Valioso : ¿Contribuye la API a los resultados de la empresa y mejora la satisfacción del cliente?

Ronnie Mitra , de CA Technologies , presentó por primera vez esta correlación con UX Honeycomb. Especificó que "en el espacio de la API construimos algo en una máquina para que lo use una máquina, y esto es incorrecto porque hay personas del otro lado de los clientes de la API".

Ronnie Mitra durante su presentación en la plataforma cumbre

Mitra cree que lo que falta es un proceso de diseño de API similar al que emplean los diseñadores de UX. Deberíamos seguir lo que UX ha estado haciendo porque las API impactan claramente en cómo los usuarios finales experimentan el producto. Los expertos en UX generalmente siguen un proceso iterativo que involucra una investigación inicial del usuario , donde comprenden cómo los usuarios percibirán la aplicación. Este paso es tan importante que Nielsen Norman Group, reconocido en la industria de UX, considera que no hay UX sin él . [Bueno, xclass = ”text-center”] ”Las decisiones de diseño de API realmente impactan la experiencia del usuario final, no solo cómo los desarrolladores lo están consumiendo ". - Ronnie Mitra, CA Technologies
[botones para compartir fácilmente = ”twitter, facebook, linkedin, google” contadores = 0 native = ”no” url = ”http://nordicapis.com/?p=2745 ″ text =” Las decisiones de diseño de API realmente impactan al usuario final experiencia, no solo cómo la consumen los desarrolladores - @mitraman de @CAinc ”] [/ bueno]http : // nordicapis com /? 2745  text = ”Las decisiones de diseño de API realmente impactan la experiencia del usuario final, no solo cómo la consumen los desarrolladores - @mitraman de @CAinc”] [/ bueno]

El segundo paso está relacionado con la ideación , o cómo generar muchas ideas diferentes en poco tiempo. La creencia es que cuantas más ideas tienes, más creativo eres, y esto a su vez conduce a un mejor diseño. Finalmente, el último paso de la iteración es la prueba y la validación . Esto se puede hacer mediante procesos manuales o automatizados. Estos pueden variar desde simples entrevistas a usuarios hasta pruebas A / B totalmente automatizadas que revelan qué funciones de API se utilizan y con qué frecuencia.

Según Mitra, debe centrarse en la parte de la ideación del proceso y esbozar tantos escenarios de API como sea posible. La creación de diferentes bocetos lo ayuda a comprender mejor de qué se trata su API y cómo finalmente se consumirá. La creación de bocetos implica definir los recursos de API compatibles, su vocabulario y qué operaciones manipularán esos recursos.

Los bocetos son el primer paso de un proceso que Mitra cree que será un lugar común en la fase de diseño inicial de los productos API. Empiece generando tantos bocetos como sea posible para proporcionar un prototipo de baja fidelidad. Los desarrolladores pueden utilizar este primer prototipo para probar cómo responde la API a sus solicitudes. API Blueprint , por ejemplo, le permite generar rápidamente maquetas que pueden probarse con cualquier especificación de cliente existente; de manera similar, puede crear API virtuales con SmartBear's Ready! APIEste paso inicial, cada vez más importante, es solo el primero en el proceso de entregar lo que un cliente necesita. A continuación, debe entregar una segunda prueba de concepto (PoC) de alta fidelidad. Esto se puede hacer lanzando un piloto dentro de la empresa (si su API es interna) o dentro de un número preseleccionado de usuarios (si la API es pública). Con otras tecnologías como Swagger o RAML , puede lograr resultados similares.

Lo que quieren los consumidores

Al final de este proceso, debe tener una API que se centre en lo que necesitan los desarrolladores y los usuarios finales. Incluir este proceso lo ayuda a crear una API que no solo parece mucho más simple, sino que es mucho más fácil de usar. Las API no deberían parecer complicadas porque, según Johannes Lundberg de 46Elks, "el valor real está en eliminar la complejidad para los consumidores de API".

Lundberg cree que las características de la API son "pegajosas". Esto significa que no debe eliminarlos en algún momento en el futuro. Eliminar o cambiar una función podría romper las implementaciones de cualquier cliente existente, y eso debe evitarse . Harmon agrega que pensar en cómo las diferentes API se conectan entre sí es más importante que definir una única especificación de API. Se necesita el pensamiento sistémico en lugar de un proceso de pensamiento único.

Una posible forma de cerrar esta brecha entre lo que ofrece la API y lo que los consumidores realmente quieren es adherirse al diseño de HATEOAS de manera más estricta. HATEOAS, o H ypermedia un s t él E Ngine o f A plicación State, dice que los consumidores interactúan con las API en su totalidad a través de hipermedia, que los proveedores generan de forma dinámica. Al emplear técnicas de hipermedia, los proveedores pueden ofrecer sugerencias sobre cómo usar la API al inspeccionar las respuestas ellos mismos, haciendo que los clientes se adapten mejor a cualquier cambio en particular. Aunque esta estrategia libera a los proveedores de tener que entregar y mantener documentación de alta calidad, traslada la responsabilidad de comprender la API a las implementaciones de los clientes.

Varios oradores mencionaron HATEOS y cómo podría ayudar a la industria de las API a evolucionar hacia un espacio más orientado al consumidor. Jakob Mattsson , de FishBrain, cree que "un consumidor debería interactuar con la aplicación a través de los hipervínculos proporcionados en las respuestas" y que "no debería requerir conocimientos previos para navegar por la estructura de respuesta de la API". Si bien todavía estamos lejos de esta realidad, Mattsson sugiere tres reglas que debe seguir si desea realizar la transición rápidamente:

  1. Sin fijación : no debe utilizar jerarquías o nombres de recursos fijos.
  2. Sin tipos : debe utilizar tipos de medios estandarizados y nombres de relaciones, no los que cree.
  3. Sin conocimientos previos : debe utilizar un único punto de entrada, donde el estado se rige por la selección del cliente en las opciones proporcionadas por el servidor.

El uso de tipos de medios estandarizados es probablemente la más importante de estas reglas. Según Irakli Nadareishvili de CA Technologies, "la clave es el tipo de medio". Nadareishvili cree que los tipos de medios estándar son los que los clientes usarán para comprender de qué se trata la API y cuál es el formato de respuesta esperado. Los clientes obtendrán esa información de los tipos de medios y se ajustarán en consecuencia. La familiaridad es muy importante y eso solo se puede obtener con un conjunto de tipos de medios estandarizados que comprendan tanto los proveedores como los consumidores.

Si bien el futuro parece prometedor, todavía estamos muy lejos de nuestro objetivo. Pau Ramon de Redbooth cree que HATEOS no se utilizará ampliamente en el corto plazo. El consejo de Ramón por ahora es “apostar por APIs planas” que brinden respuestas con los datos solicitados y nada más. Harmon no es tan radical, y su consejo es "ser inteligente sobre el tamaño de los recursos porque no hay una respuesta perfecta para esto".

Conclusión

El diseño de API para humanos no debería ser demasiado complicado, pero debería hacerse siguiendo algún proceso probado. La Cumbre de la Plataforma Nórdica de API proporcionó evidencia de un consenso que confirma que los profesionales de API deben seguir los mismos procedimientos que los expertos en UX han estado utilizando durante décadas. Al final, las API serán consumidas por personas reales. Por lo tanto, se deduce que deben aplicarse los principios de UX.

En el aspecto técnico, aún no está claro qué estándares y paradigmas deben seguirse y cuándo. Por un lado están los seguidores de HATEOAS e Hypermedia que quieren impulsar la estandarización de las API que se pueden consumir por completo sin ninguna intervención humana. Por otro lado, están la mayoría de los profesionales de API, que creen que los estándares actuales vivirán durante mucho tiempo y están seguros de que no hay una manera fácil de implementar una API de "talla única".

Sea cual sea su posición sobre esta controversia, una cosa está clara: las API afectan los resultados de su negocio y la forma en que los clientes reales perciben su producto. Esto hace que sea imperativo que preste atención al diseño de API y siga los principios de UX descritos anteriormente.

¿Tiene una opinión diferente? ¿Qué piensas sobre esto? ¡Deje un comentario aquí o póngase en contacto para discutir esto más!

Recursos

Aquí están los videos de la Cumbre de la Plataforma de NordicAPIs de las conversaciones a las que se hace referencia en este artículo, por orden de aparición:

  • Diseño de API de escala ", Jason Harmon
  • Ciclo de vida del diseño de API ", Honza Javorek
  • El arte del diseño de API eficaz ", Ronnie Mitra
  • La arquitectura de una plataforma API ", Johannes Lundberg
  • Su API basada en HTTP no es RESTful ", Jakob Mattsson
  • El desafío de Internet de las cosas: crear API que duren décadas ", Irakli Nadareishvili
  • “ Clientes REST ”, Pau Ramon

Publicar un comentario

0 Comentarios