Header Ads Widget

Ticker

6/recent/ticker-posts

Emuladores de API: ¿Deberían ser parte de su estrategia de producto API?

 



Seamos sinceros; el enfoque actual para crear API está ocupado . Queremos implementar en todas partes, escalar rápidamente y automatizar tanto como podamos. Sin duda, esto presenta algunos nuevos desafíos. En particular, ¿cómo se supone que debemos construir contra API que estén incompletas o inestables?

Los emuladores de API son una solución prometedora para este problema. En este artículo, le presentaremos algunos de los conceptos básicos de los emuladores, incluidos qué son, cómo puede usarlos y cómo comenzar a crear los suyos propios.

Hemos basado esta guía en una charla impartida por Steve Sfartz , arquitecto de API de Cisco, en nuestra Cumbre de API de Austin 2019. Mira la charla aquí:

¿Qué es un emulador de API?

Como sugiere el nombre, un emulador de API imita la funcionalidad de su API. El trabajo de un emulador es proporcionar respuestas predecibles contra las cuales los desarrolladores pueden construir, incluso si la API en sí no está disponible o cambia constantemente.

Para que un emulador sea útil, no necesita implementar todo el conjunto de características de su API. Sin embargo, es necesario implementar al menos un caso de uso completo.

Emuladores vs servidores simulados

Los servidores simulados son otra opción popular para recrear la funcionalidad de una API. A diferencia de los emuladores, que generalmente se ejecutan en su máquina local, los servidores simulados son servidores. Esto significa que debe poner en marcha un nuevo servidor para cada servidor simulado que cree, a menudo confiando en herramientas de terceros para hacerlo.

Ninguna opción es necesariamente superior, pero hay algunas circunstancias en las que una encaja mejor que la otra, ¡hablaremos de eso más adelante!

Emulador de Webex de Steve

Steve dice que experimentó por primera vez con emuladores cuando creó un chatbot para la herramienta de colaboración de Cisco, Webex Teams. Creó e implementó un bot que respondería a los webhooks proporcionados por Webex, pero no funcionó como se esperaba.

Desafortunadamente, Steve no tenía una manera fácil de probar el comportamiento de su código, ya que se basaba en webhooks de Webex. Sus únicas opciones eran implementar nuevos servicios continuamente, o crear una herramienta que emulara los webhooks proporcionados por Webex, a voluntad ...

¡Y así nació el emulador de API de Webex ! Si observa la documentación, verá que el caso de uso principal del emulador es "probar y depurar los chatbots de Webex". Como resultado, imita sólo los recursos necesarios para ese caso de uso: /rooms/memberships/messages/attachment/actions/webhooks.

Steve demostró la herramienta durante su charla. Con solo unos pocos clics, el emulador estaba en funcionamiento. Los emuladores no suelen tener una interfaz gráfica de usuario, y la de Steve no fue la excepción: Emulator started on port: 3210la línea de comandos decía.

Luego, Steve se mudó a una instancia de Postman donde podía enviar solicitudes al emulador, con localhostla URL de la API. Las respuestas son exactamente las que esperaría de una API; consulte este ejemplo con el /people/mepunto final:

{
"id": "Y2lzY29zcGFyazovL3VzL1BFT1BMRS85MmIzZGQ5YS02NzVkLTRhNDEtOGM0MS0yYWJkZjg5ZjQ0ZjQ", "emails": [ "stsfartz@cisco.com" ], "displayName": "Stève Sfartz", "nickName": "Stève", "firstName": "Stève", "lastName": "Sfartz", "avatar": "https://cdn-images-1.medium.com/max/1600/1*Iel5Q6qAxgBdl_IHUx3scA.jpeg", "orgId": "Y2lzY29zcGFyazovL3VzL09SR0FOSVpBVElPTi8xZWI2NWZkZi05NjQzLTQxN2YtOTk3NC1hZDcyY2FlMGUxMGY", "created": "2017-07-18T00:00:00.000Z", "type": "person" }

Para implementar la funcionalidad de webhook, Steve usó una segunda herramienta llamada ngrok para crear una URL segura para acceder a su computadora. Luego, estableció la URL de destino del webhook Postman en esta URL ngrok . Después de enviar un mensaje de Postman a su emulador, Steve pudo abrir la interfaz de administración de ngrok y ver cómo se activaba su webhook.

Eso fue todo lo que necesitó Steve para lanzar un emulador de API de Webex que le permitiría probar sus bots a fondo. Una vez más, puede ver el funcionamiento interno completo del emulador en GitHub .

Consulte también: Cómo utilizar servidores simulados para un desarrollo ágil

¿Por qué utilizar un emulador?

Después de la breve demostración de Steve, queda claro de inmediato que hay algunas razones por las que podría considerar usar un emulador.

Para empezar, los emuladores son excelentes para realizar pruebas . Puede iniciar el emulador en cuestión de milisegundos y no tiene que preocuparse por administrar las restricciones de API del mundo real, como la limitación de velocidad.

A continuación, los emuladores pueden ayudar con los procedimientos de garantía de calidad . Por ejemplo, si tiene un servicio en la nube que cambia con el tiempo, es probable que comience a comportarse de manera diferente. Un emulador puede brindar beneficios como la no regresión y el control de versiones, para que pueda saber con precisión cómo responde el código a las iteraciones más antiguas de su servicio.

Otro beneficio de los emuladores radica en el diseño de API . En lugar de implementar directamente nuevas funciones en una API de producción, los gerentes de producto pueden agregar esa nueva funcionalidad a un emulador con una sobrecarga técnica significativamente menor. Luego, los desarrolladores pueden probar fácilmente el nuevo comportamiento y proporcionar sus comentarios antes de editar la API de producción.

El beneficio final: usar un emulador de API no requiere acceso a Internet . Entonces, si desea trabajar en su aplicación mientras está acampando en el desierto, ¡ahora es posible!

Relacionado: 5 beneficios de usar la virtualización para probar su API

Consejos para construir su emulador

Aunque crear un emulador puede parecer bastante abrumador, es más fácil de lo que cree. Steve dijo que ha creado emuladores en solo dos días, y tuvo la amabilidad de compartir algunos consejos sobre cómo puedes hacer lo mismo.

Lo más importante es que Steve le recomienda que piense en grande, pero comience con algo pequeño . Empiece por implementar un caso de uso completo. Por lo tanto, no se extienda demasiado: concéntrese en los casos de uso que necesita especialmente.

A continuación, manténgalo liviano; después de todo, es por eso que está creando una simulación, y no solo otra API. Recomienda mantener la aplicación en memoria.

Finalmente, sugiere usar un marco HTTP de bajo nivel para que pueda modificar libremente las cargas útiles y los encabezados. Esto le permite imitar el comportamiento de su API con la mayor precisión posible. Steve usó Express.js para su emulador.

Lea también: Cómo simular servicios web durante el desarrollo

Pensamientos finales

Si es un proveedor de API, Steve cree que debería considerar los emuladores de API como parte de su estrategia de producto API. El desarrollo del emulador no debería llevar mucho tiempo (debería intentar construir un emulador en horas o días, no en semanas). Podrían ayudar enormemente a sus desarrolladores a construir en algunos casos de uso específicos.

Lo mejor de todo es que si abre el emulador de código abierto, tanto sus desarrolladores internos como su ecosistema de desarrolladores podrán (y probablemente lo harán) contribuir con algo útil. ¡Oh, no olvides un descargo de responsabilidad de "mejor esfuerzo"!

Publicar un comentario

0 Comentarios