Como usuario quiero un nuevo endpoint que ya tenga una estructura lógica para peticiones de consulta de datos. Los datos estarán moqueados, pero la respuesta respetará el formato.

Criterios de aceptación

• El endpoint lee los parámetros de entrada y los loguea.

• El endpoint responde 200 OK, en el body una estructura coherente con lo definido en la hu-01-02.

Decidir el formato de la petición básica

Es una historia de documentación.

Criterios de aceptación

• Se produce documentación sobre la URL y los formatos de petición y respuesta, por ejemplo, en RAML.

• La documentación se encuentra en un lugar lógico dentro del directorio doc.
  hu01-03.md

Responder al endponint respetando los formatos, pero con datos moqueados.

Como usuario quiero un nuevo endpoint que ya tenga una estructura lógica para peticiones de consulta de datos. Los datos estarán moqueados, pero la respuesta respetará el formato.

Criterios de aceptación

• El endpoint lee los parámetros de entrada y los loguea.

• El endpoint responde 200 OK, en el body una estructura coherente con lo definido en la hu-01-02.

Configurar npm con la tarea de pasar el eslint

Hacer un test tonto

Como desarrollador quiero poder lanzar los tests. Necesito al menos la estructura básica de los mismos.

Criterios de aceptación

• Al lanzar los tests hay al menos un test que funciona, aunque sea tonto.hu01-01.md

Responder a un endpoint dummy

Como usuario del WS quiero llamar a un endpoint, sólo para ver que funciona.

Como administrador quiero ver los logs de la aplicación.

Criterios de aceptación

• La aplicación produce logs en consola.

• Se han definido los niveles de logs que habrá.

• Una clase se ocupará del logging, de forma que más adelante sea casi inmediato cambiar el modo de loguear.

• Los logs constan de un nivel, un mensaje, y un objeto con datos relevantes.

• SHOULD: crear una estructura para moquear los logs y poder comprobarlos en los tests.

• SHOULD: usar ya winston para poder luego cambiar más fácilmente.

Como usuario del WS quiero llamar a un endpoint, sólo para ver que funciona.

Criterios de aceptación

• Se puede llamar a un endpoint REST con GET.
• La respuesta será 200 OK, con cuerpo {}.

...