Header Ads Widget

Ticker

6/recent/ticker-posts

Funcional versus útil: ¿Qué hace que una API sea útil?

 

what_makes_a_useful_api_nordic_apis-01

Es muy fácil decir que si existe una API, entonces es útil. Después de todo, si un desarrollador crea una API, debe haberla creado para algún propósito. Sin embargo, lo que es funcional no siempre es útil y, a la inversa, lo que es útil no siempre es funcional. El verdadero éxito requiere ambas facetas.

En este artículo, abordaremos la idea de qué hace que una API sea útil y funcional , y por qué es importante . Nos sumergiremos en un ejemplo del mundo real, demostraremos algunas aplicaciones hipotéticas e incluso estableceremos una rúbrica mediante la cual su API actual o futura puede ser criticada, y posiblemente mejorada, con el objetivo final de ayudar a los desarrolladores a descubrir el núcleo de su API. valor .

Una cuestión de terminología

La cantidad de API en la naturaleza es simplemente asombrosa: ya sea que estemos hablando de API que impulsan ciudades inteligentes o API que ofrecen algo tan simple como el correo de voz , las ofertas actuales son tan diversas como numerosas. Con una gama tan amplia de sistemas, discutir las cualidades objetivas de funcional versus bueno es bastante difícil.

Debido a la naturaleza de las críticas subjetivas y objetivas de una gama tan extrema de sistemas y servicios, los términos indudablemente se confunden, combinan o cambian; lo que un usuario puede encontrar útil, otro puede encontrar inútil y viceversa. Para considerar adecuadamente una API sobre una base objetiva, en lugar de subjetiva, necesitamos establecer algunas definiciones básicas.

Definición de funcional

Cuando hablamos de una API funcional, ¿qué queremos decir realmente? Cualquier API que entregue una llamada según lo solicitado podría definirse como funcional. Objetivamente, la funcionalidad se puede definir como la entrega de datos cuando se solicitan en un formato utilizable .

Sin embargo, al diseñar una API, todas las funciones del mundo serán absolutamente inútiles a menos que se entreguen de una manera que sea utilizable . Piénselo de esta manera: digamos que está invitado a cenar en la casa de un amigo y no está seguro de cómo llegar a su casa. Les pides direcciones. Proceden a darte instrucciones citando puntos de referencia tan notables como "ese extraño letrero verde" y "ese puesto de tacos realmente bueno al que fui con Mark, oh, no conoces a Mark, ¿verdad?"

En esta situación social, ha recibido una buena cantidad de datos, pero esos datos no son funcionales, al menos no según sus estándares. Ninguna calle ha recibido el nombre de "ese extraño letrero verde". Lo mismo podría decirse de una API: si una API entrega datos según lo solicitado, pero de una manera no estandarizada o inutilizable por el sistema solicitante, no es realmente funcional.

¿La comida para llevar? Los sistemas funcionales funcionan según su diseño y pueden ser utilizados por el sistema solicitado .

Definición de útil

Si funcional es un término subjetivo, entonces discutir un término como "útil" es realmente abrir una lata de gusanos. Cualquier cosa puede ser útil en un sentido subjetivo: ha surgido toda una industria artesanal de infomerciales en torno a la creación de herramientas para resolver problemas que pocos de nosotros realmente hemos tenido. La utilidad en el sentido coloquial casi siempre se define mejor como "útil para mí", en lugar de "útil por diseño".

Útil de manera objetiva, sin embargo, es mucho más específico que cualquier definición personal de utilidad. Cuando se habla de si una API es útil o no, ¿de qué hablamos? Ciertamente no la funcionalidad, que ya ha sido manejada por nuestra discusión sobre el término "funcional" anterior.

Algunas cosas en la vida son más fáciles de encontrar cuando buscas lo que no son. Los astrónomos mapean los agujeros negros no buscando directamente las manifestaciones físicas, sino la ausencia de espacio alrededor de un agujero negro. Los pintores crean no solo con acrílico y óleo, sino también con "espacio negativo", o áreas de lienzo sin colores sólidos. A los músicos les gusta cambiar la dinámica, acentuando las piezas ruidosas con un silencio repentino.

Al considerar qué es "útil" en un sentido objetivo, también podemos utilizar esta misma técnica para identificar lo que no es "útil". Una API útil no es confusa. Los nombres de funciones largos y difíciles de recordar, los parámetros que no tienen sentido y la documentación deficiente no se relacionan con la funcionalidad: la incapacidad de la persona que realiza la llamada para recordar nombres largos no es una cuestión de funcionalidad, sino de la experiencia del usuario.

Asimismo, una API útil no es aquella que está diseñada para el momento. Los sistemas evolucionan, y cualquier cosa que no tenga la capacidad de evolucionar bien podría no existir en el mundo técnico. Diseñar una API para que cumpla una función limitada, sin escalabilidad ni extensibilidad, genera una API incorrecta y crea un entorno empresarial estancado.

De esta manera, "útil" tiene mucho que ver con la experiencia del usuario y el desarrollador más que con la funcionalidad del sistema.

¿La comida para llevar? Los sistemas útiles son tan complejos como deben ser y escalan bien a través de implementaciones e iteraciones .

Por qué es importante

¿Por qué importa todo esto? Si su API ofrece la funcionalidad deseada, ¿no es funcional? Y si la API tiene una experiencia de API relativamente bien diseñada y entrega los datos solicitados, ¿no es útil?

Uno de los mayores escollos que puede hacer un desarrollador o una empresa es considerar su producto o servicio desde la perspectiva limitada de su experiencia personal. El director ejecutivo, el director de marketing y el equipo de soporte técnico no son las únicas personas que utilizarán su producto, servicio o sistema; hay un mundo entero que se mueve más rápido de lo que podemos comprender, y un paso en falso podría significar la diferencia entre el éxito y fracaso .

Este tipo de pensamiento de "canal único" es exactamente lo que causa la combinación de términos cuando se consideran API funcionales y útiles; en el mejor de los casos, su usuario utilizará su API todos los días en una variedad infinita de formas opacas y transparentes , y su experiencia se reflejará en su negocio; por eso, el diseño, la naturaleza y la calidad de la API lo son todo. Además, su negocio y su sistema crecerán orgánicamente a medida que su cliente use su API para cada vez más cosas; si su sistema está mal diseñado, esto no ocurrirá y provocará un estancamiento.

Para obtener más información, lea Las API están alterando nuestra forma de pensar

Fracaso de la vida real

Sin embargo, toda esta redefinición de términos y combinación de conceptos se elimina fácilmente cuando miramos los casos de fracaso del mundo real. El 14 de noviembre de 2014, Netflix cerró oficialmente su API pública . Esto no fue una gran sorpresa para muchos desarrolladores que utilizaron la API, ya que había estado cerrada a nuevos desarrolladores casi dos años antes, con rumores y rumores de su inminente cierre completo que emana a partir de entonces.

La API se utilizó en servicios como CanIStreamIt ?, un servicio que informaba si un título estaba disponible para transmitir en una variedad de servicios, y A Better Queue, que sugería nuevas películas basadas en títulos anteriores utilizando un algoritmo avanzado. Dado esto, ¿por qué se cerró y por qué se considera el paradigma de una API no "útil" y no "funcional"?

La API estaba plagada de problemas. Los cambios radicales en las funciones y las solicitudes a menudo se produjeron con poca advertencia, lo que interrumpió la funcionalidad para los usuarios de servicios de terceros. La documentación era incompleta, general y dispersa entre varios foros y documentos. La API pública era en realidad dos API independientes que funcionaban como una, y ninguna de las dos proporcionaba una funcionalidad completa.

El desarrollo de la API pública fue demasiado privatizado, un pecado capital del desarrollo de API , sin ninguna comunicación entre los desarrolladores de la API y los desarrolladores que la utilizaron. Las claves de API a menudo caducan sin previo aviso, lo que genera problemas de funcionalidad que rompen el sitio para muchos desarrolladores. Estos problemas, y más, hicieron que los desarrolladores perdieran interés, lo que provocó una falta de innovación ; Se puede argumentar que este fue un ciclo de negatividad, con la API pública sin soporte debido a la falta de innovación de terceros, lo que a su vez fue causado por la falta de soporte de API pública.

En última instancia, aunque la API funcionó bien y brindó una experiencia suficiente para los usuarios, simplemente no era "útil" o "funcional" de acuerdo con nuestras definiciones. La API nunca recibió el soporte que necesitaba para despegar y se cerró como resultado de la falta de implementación e innovación. En el mismo año en que Netflix recibió soporte de Occulus Rift a través de un evento de piratería oficial utilizando su sistema de API privado, se retiró su API pública.

Para obtener más información sobre la desaprobación de la API pública, consulte Historia de las principales retiradas públicas

Una rúbrica para el éxito

Dado que hemos tomado nuestra terminología subjetiva y hemos creado una métrica objetiva mediante la cual podemos juzgar una API, tomemos todo lo que hemos aprendido y aplíquelo en una rúbrica general.

Para ser funcional y útil , la API debe exhibir cinco cualidades básicas:

  • Buena documentación : la documentación puede hacer o deshacer su sistema. A medida que su API aumenta en capacidad, también aumenta en complejidad, e incluso el sistema más poderoso del mundo es completamente inútil si nadie sabe cómo operarlo. Ejemplo: "getResults devuelve los resultados de la encuesta del servidor".
  • Funciones y llamadas simples : incluso si documenta su API de manera efectiva, existe un gran peligro en lo que está documentando. ¿Las funciones y llamadas son fáciles de recordar? ¿Tienen sentido sus nombres? ¿Lo que hacen está implícito en sus nombres, lo que conduce a una mejor comprensión inicial? Asegurarse de que su sistema tenga sentido es tan importante como asegurarse de que otros lo entiendan. Ejemplo: "UserID" en lugar de "UserIDBooleanCustom"
  • Formato de datos utilizable : los datos deben ser utilizables; de lo contrario, es solo una buena colección de números y símbolos. Organizar los datos de manera que se puedan vincular a otros sistemas no solo hace que su API sea más poderosa, sino que la hace extremadamente extensible. Ejemplo: "UserID = 555" en lugar de "auth001991887_sheet8881993_resourcerequestsid = 12399nn18373_userid_customvalue = charlie_userIDvalueset_userIDvalue = 555"
  • Escalabilidad preparada para el futuro : considere la arquitectura de su API y elija una opción adecuada. No elegir una arquitectura que admita el tipo de solicitudes que desea llamar, así como las solicitudes que podría considerar implementar en el futuro, conduce a una API de estilo "curita" destinada a resolver su problema actual, mientras crea nuevos problemas en el futuro. Ejemplo: si está tratando con una gran cantidad de datos de procesamiento lento, pero necesita implementar funciones en el futuro que requieren alta seguridad, use SOAP en lugar de REST.
  • Planificación adecuada del proyecto : ¡manténgalo simple! Al desarrollar su API, no hay razón para segmentar el desarrollo en subproyectos, sub-API, equipos de desarrollo, etc., ya que hacerlo puede causar diafonía entre equipos, fallas en la entrega de productos cohesivos y confusión entre su base de usuarios. Ejemplo: desarrolle una única API pública en lugar de múltiples derivaciones de una API (a menos que se justifique específicamente).

Al implementar estas cinco cualidades básicas y considerar los valores que se muestran a lo largo de este artículo, no solo puede asegurarse de que su API sea funcional y útil, sino que su implementación, percepción pública y usabilidad sean lo mejor posible.

Conclusión

Gran parte del mundo es subjetivo: el arte, la moda, el entretenimiento, todo está relacionado con sus elecciones y tendencias personales. Sin embargo, a medida que la tecnología avanza y el mundo de las API se transforma en potencias de activismo, arte, tecnología y comercio , se deben cumplir ciertos estándares. Ya pasaron los días en los que una API podía recibir algunos cientos de visitas de una base dedicada de asistentes técnicos: el usuario promedio requiere mucha más documentación, información y una experiencia de usuario mucho mejor que nunca.

Seguir los pocos conceptos simples descritos en este artículo y considerar el ciclo de vida del diseño de su API como un viaje en lugar de una carga no solo puede generar éxito, sino que puede convertirse en un éxito por derecho propio.

Publicar un comentario

0 Comentarios