Nice to haves y funciones aptas para un MVP

Por último, voy a describir algunas funciones que estaría bien ponerle a mi cliente HTTP, y cuáles vale la pena implementar al principio y cuáles para más adelante. O incluso cuales puede que nunca implemente.

Por el momento me interesa que mi cliente haga lo mínimo esencial para por lo menos empujar el proyecto para adelante. Es decir, me interesa:

  • Que se pueda introducir la URL a la que tirar la petición.
  • Que se pueda seleccionar el método HTTP a utilizar (GET, POST…)
  • Que se pueda ponerle un body a las peticiones web (para enviar datos).
  • Que se puedan elegir las cabeceras HTTP a utilizar.
  • Que se pueda visualizar la respuesta y las cabeceras de la misma.

La interfaz de usuario debería ser por el momento algo simple como el siguiente wireframe horrible y feo que he pintado en dos minutos con el ratón.

Un wireframe de una interfaz de usuario, muestra dos columnas debajo de una barra de herramientas.
Graphics design is my passion.

Y ahora, los nice to have una vez que haya un prototipo:

  • Evidentemente, un historial en condiciones sería deseable, ya que es el factor que hace que valga la pena usar un cliente gráfico y no simplemente tirar un cURL o un HTTPie.
  • Parametrizar con variables, para que la cabecera Authorization valga Bearer ${TOKEN}, siendo ${TOKEN} una variable que cambia según si estás en desarrollo, staging o producción.
  • Guardar peticiones en carpetas, para poder documentarlas y reusarlas en el futuro. En formato texto plano, para hacerlas fáciles de exportar e incluso fáciles de versionar con Git.
  • Poder exportar como cURL, HTTPie, Axios, net/http… Que no importar, por ahora.

Y unos nice que no son tan esenciales pero que estaría bonito:

  • Peticiones batch, por ejemplo, que una petición dependa de otra. Esto para que se lance una petición de login antes de poder usar una petición de consulta a una API privada vendría bien.
  • Importar y exportar como OpenAPI.

Cosas que no le veo mucho sentido pero que puede ser bonito:

  • Un cliente REST, GraphQL o SOAP. Son arquitecturas hechas por encima de HTTP, pero sigue siendo HTTP. No sé qué valor tiene entregar una plantilla de un soap:envelope o envolver una query GraphQL por ti. Sin embargo, todo es mirarlo.
  • Poder ejecutar tests y código tras la petición, por ejemplo para verificar la respuesta o simplemente para guardar la API key que venga del servicio web en una variable. Sin embargo, ¿cómo se implementa de forma segura y sin que sea un peligro?