Seleccionar PƔgina

La estrategia «Primero la API

En Polder Knowledge, a menudo aplicamos una «estrategia API First». Existe cierto debate sobre lo que significa realmente API First, pero en Polder Knowledge lo interpretamos como un proyecto suelto que contiene la lógica empresarial de una aplicación. Esta lógica empresarial puede utilizarse hablando con API REST y RPC. La ventaja de crear una API independiente es que resulta mÔs fÔcil separar las distintas preocupaciones. Gracias a la existencia de esta API, podemos crear aplicaciones para web, móviles y tabletas, y construir sitios web que hablen con la misma API y, por tanto, compartan la lógica. ¿El resultado? Los desarrolladores de móviles pueden centrarse por completo en su aplicación, los desarrolladores de front-end pueden centrarse por completo en su sitio web y los desarrolladores de back-end pueden centrarse únicamente en la propia API. Trasladamos la lógica a la API, en lugar de gestionarla en las aplicaciones.

Para desarrollar APIs, nuestra principal arma es Apigility. Apigility viene con una gran cadena de herramientas que hace posible construir API estables y profesionales. La herramienta es compatible con OAuth 2.0, JSON Hypertext Application Language (HAL) y Problem Details para API HTTP, lo que hace posible que se haga mucho trabajo por nosotros. Esto nos permite centrarnos por completo en la lógica empresarial de la aplicación.

Desarrollar API aplicando la estrategia «La API primero» no significa que la API tenga que estar terminada antes de construir la aplicación móvil o el sitio web; a menudo se desarrollan simultÔneamente. Esto significa que los desarrolladores de la API necesitan una forma de ejecutar y probar sus llamadas HTTP. Por suerte, existe una herramienta impresionante que es capaz de hacer eso por nosotros: Postman

Desarrollo con Postman

Postman te permite organizar tus llamadas HTTP; te permitirÔ configurar todas las llamadas API disponibles, para que puedas guardarlas y reutilizarlas. También es posible compartir tu colección de llamadas API con tus colegas. Te presentaré algunos consejos que han sido muy útiles para el equipo de Polder Knowledge durante el desarrollo. Estos consejos pueden parecer obvios para algunos y pueden ayudar a otros. ”OjalÔ puedan ayudarte a ti!

Organización y categorización

Una aplicación común puede contener docenas de APIs. Las API REST suelen configurarse con un servicio sobre el que puedes aplicar acciones (los verbos HTTP). Por ejemplo: para crear una nueva entidad, lo normal es que ejecutes una solicitud POST al punto final de esa entidad. Hemos aprendido que es útil organizar estos puntos finales con las colecciones que ofrece Postman. En la captura de pantalla siguiente, puedes ver que hemos creado una colección llamada Evolve. Esta colección contiene una serie de puntos finales que hemos clasificado en su propia carpeta.

Convención de nomenclatura

Anteponiendo a la llamada a la API el prefijo REST o RPC, queda claro qué tipo de llamada se realiza. Diferenciamos REST y RPC entre sí anteponiendo a la llamada el tipo. A continuación, es útil dejar claro si estÔs ejecutando la solicitud en la colección o en la propia entidad.

Ver modos

Todos somos humanos, así que se cometerÔn errores, ¿verdad? Al probar tus llamadas a la API, a menudo ocurre que esperas JSON, pero se produce un error del servidor. Cuando una aplicación no gestiona correctamente la cabecera Accept, se mostrarÔn errores HTML. Postman te permite cambiar entre vistas renderizadas y vistas sin procesar. Esto es extremadamente útil en los casos en los que se producen errores del servidor, ya que te permite leer los datos de forma renderizada. Postman también analizarÔ JSON y XML, para que tus datos sean mÔs fÔciles de leer.

Autorización

Cuando tu API haga uso de la autorización, Postman te permitirÔ configurar la autorización para tus llamadas a la API. Obtén fÔcilmente tokens de acceso OAuth, utiliza la Autorización BÔsica o la Autorización Digest.

Compartir

Una vez que tus llamadas a la API estƩn bien organizadas, podrƔs compartirlas. Puedes compartir la API a travƩs de la nube Postman o puedes exportar fƔcilmente la API a un JSON. Estos archivos JSON se pueden enviar a un repositorio o puedes compartirlos con tus compaƱeros de equipo.

Variables y entornos

Imagina que tienes un servidor web local al que puedes acceder a travƩs del dominio webserver01.host. Tu colega tambiƩn tiene un servidor web local al que se puede acceder a travƩs de miproyecto.host. Una vez configuradas tus llamadas a la API, introduces la URL de tu propio servidor web. Ahora exportas tu API a un archivo JSON y tu colega lo importa de nuevo. Tu colega verƔ todas tus URL locales, lo que, como puedes imaginar, no es lo ideal. Esto puede solucionarse simplemente utilizando variables. Las variables se pueden utilizar en cada campo que se pueda rellenar dentro de Postman.

Postman hace uso de entornos, que te ayudan a cambiar el conjunto de variables por proyecto en el que trabajas.

Una vez creado tu entorno y añadidas las variables, puedes utilizarlas donde quieras. ”Postman incluso te ofrece autocompletado!

Prueba

Ya tienes tu API estructurada y organizada, e incluso puedes compartirla con tus compañeros de equipo. Pero, ¿qué fantÔstico sería si pudieras asegurarte de que la respuesta de la API es vÔlida? ”Pues Postman te ofrece esta posibilidad!

Asegúrate de echar un vistazo a Newman también, ya que ofrece la posibilidad de ejecutar tus pruebas Postman en la línea de comandos. Esto significa que puedes engancharlo en tu cadena de construcción de Integración Continua.

En resumen…

Postman ofrece un gran conjunto de herramientas para optimizar tu flujo de desarrollo. Organizar, colaborar y probar todo es posible con Postman. Espero que estos consejos te hayan ayudado a optimizar tu flujo de desarrollo. Asegúrate de ponerte en contacto con nosotros a través de Twitter (@Polder Knowledge) si tienes algún otro consejo.