Header Ads Widget

Ticker

6/recent/ticker-posts

Diseño de API y pruebas de vanguardia

 


Asegurar la funcionalidad adecuada de las API plantea las siguientes preguntas:

  • ¿Cómo decides qué puntos finales vas a exponer con tu API?
  • ¿Cómo crea toda la documentación que los desarrolladores usarán para interactuar con su API?
  • ¿Cuál es la mejor manera de verificar que su API está funcionando según lo especificado por la documentación y de acuerdo con las expectativas del desarrollador?
  • ¿Quién debería participar en el modelado de API dentro de su organización?

Cuando termine de leer este artículo, podrá responder a todas estas preguntas. El diseño y las pruebas de API son espacios muy candentes en este momento. Esto se debe a que son el medio principal para garantizar que las API no solo reflejen los procesos comerciales, sino que se utilicen de manera que generen valor tanto para los consumidores como para los proveedores.

Primero cubriremos el espacio de diseño de API, presentando las herramientas y estándares que lo ayudarán a ofrecer la mejor experiencia de desarrollador posible. Luego, nos sumergiremos en el espacio de prueba de API, ayudándolo a obtener una comprensión completa de lo que puede probar y cómo asegurarse de que su API seguirá funcionando repetidamente y de acuerdo con las expectativas. Finalmente, varios expertos de la industria compartirán sus opiniones sobre lo que depara el futuro.

Diseño API

El diseño de API es el acto de modelar una API teniendo en cuenta tres factores muy diferentes:

  • Usabilidad : cómo se utilizará la API, quién lo hará y qué casos de uso específicos deben abordarse.
  • Seguridad : qué información maneja la API; cómo debe almacenarse y transportarse; quién puede acceder a qué datos y cuándo.
  • Rendimiento : cuántos consumidores tendrá la API, cuánto tiempo pueden esperar una respuesta y qué sistemas internos afectan la velocidad de la API.

El diseño de una API puede comenzar de muchas maneras, desde una lluvia de ideas hasta sumergirse directamente en el código. Sin embargo, siempre debe producir una excelente documentación que puedan utilizar los desarrolladores y, si es posible, las aplicaciones de consumo mediante programación. Se considera una buena práctica iniciar una API documentándola y luego usar la documentación para generar el código que la implementará.

Este artículo describe tres herramientas que permiten que un diseñador de API comience describiendo cómo funciona una API y luego cómo alimentar herramientas que generarán el código que la hace funcionar.

Pavonearse

Swagger es el trabajo de Reverb Technologies , una empresa creada en 2008 que crea productos relacionados con el lenguaje. Uno de esos productos, Wordnik , fue la razón principal por la que crearon Swagger. Las solicitudes de soporte de la API de Wordnik estaban aumentando y no podían encontrar una manera fácil de documentar la API y admitir el SDK al mismo tiempo.

developer.wordnik.com fue el primer sitio web de documentación interactiva impulsado por Swagger. Ayudó a Reverb a definir lo que Swagger llegó a ser, y repitió su implementación original hasta que lo abrió en 2011. Ahora hay más de 40 integraciones del lado del servidor con Swagger y se estima que 10,000 API lo están usando para potenciar su documentación.

[Swagger] tiene éxito, en mi opinión, en gran parte porque es independiente del lenguaje, neutral con respecto al proveedor y simple. No intenta resolver todos los casos de uso y tiene opiniones hasta cierto punto. Esto ayuda a mantener la especificación esbelta y muy eficaz. Tony Tam, director ejecutivo de Reverb

Swagger es un enfoque interesante para el diseño de API porque permite a los desarrolladores escribir la definición de API solo una vez y genera automáticamente el código del servidor, el código del cliente y la documentación final. La documentación generada por Swagger es interactiva . Esto significa que los desarrolladores pueden intentar llamar inmediatamente a los puntos finales de la API sin tener que escribir ningún código.

Existen diferentes herramientas de terceros que siguen la especificación Swagger para ayudar a los desarrolladores a implementar mejor sus API. Una de estas herramientas, Apigee-127 , le permite modelar su API usando el editor Swagger y generar el código que realmente implementa los métodos API descritos en la documentación. Este es un enfoque interesante porque le permite iterar fácilmente en el diseño de su API hasta que esté satisfecho con el resultado.

RAML

RAML fue iniciado en 2013 por MuleSoft cuando se sintieron “frustrados por la falta de una forma limpia y clara de describir las API prácticamente RESTful de manera que se pudieran construir grandes experiencias en torno a esa descripción”, dice Uri Sarid, CTO de MuleSoft. RAML fue creado con el objetivo de ayudar al proceso de diseño de API con un enfoque especial en permitirle reutilizar la documentación.

Los principales objetivos de RAML son proporcionar una especificación que le permita crear documentación que sea legible por humanos, fácil de entender y que pueda desglosarse por patrones. Al cumplir con estos objetivos, RAML ofrece una combinación única de características que permite a los desarrolladores ampliarla fácilmente mediante la creación de herramientas.

RAML no es un producto […], en realidad se trata de un desarrollador de API que desea tener la capacidad de "hacer una pizarra" en una API, crear esa API y luego administrarla y aprovisionarla. Sumit Sharma, director de soluciones API de MuleSoft

El desarrollo de RAML es utilizado por un amplio grupo de empresas, incluidas MuleSoft, Intuit, Box, PayPal y Cisco. Esto ha contribuido a la creación de una especificación consensuada que ahora utilizan numerosas empresas de gran tamaño. Según SOA Software , RAML se encuentra entre una breve lista de formatos de especificación API que están ganando adopción en el espacio empresarial.

Ahora hay cientos de portales de API que utilizan RAML y una combinación de herramientas compatibles . Una de estas herramientas, API Designer, le permite editar RAML fácilmente usando su navegador. Esta herramienta, combinada con una utilidad de generación de código como JAX-RS Codegen , lo ayudará a iterar rápidamente en el diseño de su API.

Plan de API

Apiary , una empresa de diseño de API, creó el API Blueprint a finales de 2012/2013 porque descubrió que no había una forma común y sencilla de describir las API. API Blueprint es único porque utiliza el popular formato Markdown que adoran la mayoría de los desarrolladores.

Nuestro objetivo […] era crear un formato fundamentalmente muy legible / de escritura que fuera fácil de usar, pero también poderoso en lo que se podía generar a partir de él. Jakub Nesetril, director ejecutivo de Apiary

El formato API Blueprint está disponible para usar y modificar bajo la licencia MIT que permite a cualquier individuo o empresa construir sobre él, incluso comercialmente. Entre estos se encuentra SmartBear , una empresa que crea herramientas relacionadas con API. SmartBear ofrece un modelo de API para su popular herramienta SoapUI Pro que permite a las empresas probar fácilmente sus API.

Ahora hay más de 100.000 documentos basados ​​en API Blueprint en la naturaleza, lo que lo convierte probablemente en el estándar de documentación API más utilizado. La cantidad de herramientas disponibles también hace que su adopción sea muy fácil y directa, lo que le permite representar la documentación en varios formatos, generar código, probar implementaciones de API e incluso generar documentos API Blueprint a partir del código existente.

Prueba de API

Las pruebas de API a menudo se asocian con el diseño de API porque es una forma de cerrar el ciclo de iteración. Después de modelar su API, genera el código del servidor y luego ejecuta pruebas exhaustivas para comprender cómo funcionará en el mundo real.

Debes centrarte en tres factores al probar tu API:

  • Usabilidad : con qué facilidad los desarrolladores pueden utilizar su API. Este tipo de pruebas a menudo lo realizan varios desarrolladores con diferentes antecedentes.
  • Rendimiento : qué tan rápido su API puede responder a las solicitudes. Esta prueba se puede realizar mediante una herramienta de prueba automatizada como las que se describen en este artículo.
  • Cumplimiento : cuán compatible es su API con la documentación. (¿Pueden los desarrolladores seguir fácilmente la documentación y realizar solicitudes a su API?)

Recuerde que las pruebas son un proceso continuo que debe ejecutar repetidamente de forma automática, si es posible. Si no prueba su API de manera proactiva, otra persona lo hará y, si encuentra algún problema, puede crear un impacto de marketing negativo en su organización.

Veamos dos herramientas que le ayudarán a pasar del diseño de API a las pruebas de API casi en poco tiempo. Describimos POSTMAN, una aplicación basada en navegador, y Runscope, que ofrece pruebas basadas en la nube.

CARTERO

POSTMAN fue creado por Abhinav Asthana en 2012 como una estrategia para trabajar más fácilmente con API. Abhinav estaba trabajando en Yahoo! en ese momento, y no pudo encontrar ninguna herramienta que le permitiera probar fácilmente las llamadas a la API y compartir los resultados con otros desarrolladores.

En ese momento probé herramientas como Curl y no estaba muy contento con ellas. […] Lo que vi como un problema básico fue la incapacidad de comunicar a otros desarrolladores cómo funcionaba una API en particular. Abhinav Asthana, fundador de POSTMAN

POSTMAN está disponible como una aplicación de Chrome instalable , que ahora está siendo utilizada por más de 600.000 desarrolladores. POSTMAN también ofrece algunas herramientas interesantes, como Newman, que le permite ejecutar colecciones de prueba POSTMAN desde la línea de comandos y el Interceptor , lo que facilita la interceptación e inspección de cualquier llamada HTTP realizada con Chrome.

Runscope

Runscope se lanzó en 2013 como una forma de inspeccionar fácilmente el tráfico de llamadas a la API. John Sheehan unió fuerzas con Frank Stratton para resolver problemas comunes que encontraban mientras trabajaban en sus trabajos anteriores en IFTTT y Twilio .

Runscope nació de la frustración que estaba experimentando al trabajar con tantas API diferentes […] Todos los días se rompía una nueva, tenía problemas de rendimiento o era imposible integrarla. John Sheehan, director ejecutivo de Runscope

Runscope ahora está construido y mantenido por un equipo de 13 y están creciendo rápidamente a medida que ven una creciente demanda. John Sheehan cree que las API son “la única tecnología que es común a todos los lenguajes y marcos y a cada parte de la pila, desde la infraestructura hasta el usuario final”, especialmente en las empresas.

El futuro

Todavía quedan muchos desafíos por resolver en el espacio de pruebas y diseño de API. Esto requiere que las herramientas evolucionen para aportar más valor a la mesa al permitir que personas con diferentes habilidades colaboren en la definición y verificación de las API. Kin Lane , quien ha estado trabajando en el espacio tecnológico durante más de 20 años y es mejor conocido como el evangelista de API , cree que “[…] vamos a necesitar una pila sólida que ayude a todos a participar en el proceso de diseño de API, incluido propietarios de empresas que no son desarrolladores ”. Abhinav Asthana, de POSTMAN, también está de acuerdo en que “si todas las partes interesadas que están involucradas en el desarrollo y las pruebas de API pueden colaborar más rápido, las API serán más sólidas”.

Diseño de API y pruebas de vanguardia

Otro gran desafío es cómo los desarrolladores deben hacer frente al creciente número de API que las organizaciones están lanzando. Con tantos lanzamientos, habrá nuevos "productos API [y] garantizar que puedan crear sinergia con las API existentes puede ser extremadamente difícil", dice Jason Harmon , director de diseño de API en PayPal . Las aplicaciones de diseño de API deben proporcionar características que permitan a las personas definir la lógica empresarial sin tener que preocuparse de cómo se comunican los diferentes puntos finales entre sí.

Todos deberíamos trabajar duro en la lógica empresarial y dejar que las herramientas se encarguen de las tuberías. Tony Tam, director ejecutivo de Reverb

Las API también deben tratarse como cualquier otro producto en el que "[...] utiliza métricas y comentarios para comprender el comportamiento del cliente y utilizarlos para tomar decisiones de producto sobre cómo evolucionar su API", dice Jakub Nesetril de Apiary. Al seguir un enfoque centrado en métricas, puede alinear mejor su API con las necesidades de los desarrolladores y, al final, mejorar la forma en que sus clientes interactúan con su aplicación.

Una buena pregunta cuando se habla de métricas y comportamiento del cliente es qué se considera éxito. En el espacio de desarrollo de productos, el éxito se asocia a menudo con la realización de más acciones o con menos tiempo dedicado a realizarlas. Si bien esto sigue siendo una visión borrosa en el espacio API, John Sheehan de Runscope afirma que “[…] será posible probar y monitorear una API en el futuro sin tener que definir de antemano cómo se ve el éxito”.

Como puede ver, el futuro parece muy brillante y es casi seguro que buscaremos mejores herramientas en los próximos años. API Design and Testing está desempeñando un papel más importante en las empresas y se está expandiendo fuera del ámbito técnico.

Conclusión

El diseño de API no es un trabajo exclusivo para técnicos. Debido a que las API pueden afectar la forma en que operan las empresas, diferentes personas dentro de las organizaciones deberían poder contribuir al proceso de modelado de API. Ahora debería tener una buena idea sobre qué herramientas puede usar para diseñar su API y, al mismo tiempo, producir documentación lista para usar.

Hemos cubierto tres formas de diseñar API que van desde un enfoque más técnico hasta el uso de un formato de documento que cualquier persona pueda leer y comprender. Swagger es interesante porque le permite generar fácilmente código de servidor y consumidor sin ser difícil de entender. RAML está más posicionado a nivel empresarial y ofrece un estándar muy completo que le permite especificar casi todos los aspectos relacionados con una API. El estándar API Blueprint es probablemente el más fácil, ya que puede usar Markdown para escribir su especificación API que es, al mismo tiempo, su documentación.

En el espacio de prueba de API, cubrimos POSTMAN, una herramienta de prueba basada en navegador que también le permite compartir llamadas API con sus compañeros de trabajo, lo que facilita la colaboración con los consumidores de API. También cubrimos Runscope, una poderosa herramienta basada en la nube que también le permite automatizar las pruebas de API y le avisa cuando algo no funciona como se esperaba.

¿Conoce otras herramientas o servicios que ayuden con el diseño y las pruebas de API? Comparta sus pensamientos en un comentario aquí, en Twitter o en Facebook .

[Nota del editor: las API nórdicas son una publicación independiente y no han sido autorizadas, patrocinadas ni aprobadas por ninguna de las empresas mencionadas en este artículo; sin embargo, SmartBear Software, SOA Software, MuleSoft, Apiary, Apigee y Twilio son socios de eventos de las API nórdicas.]

Publicar un comentario

0 Comentarios