Es conveniente introducir primero el diseño que hemos decidido seguir antes de entrar en detalle con las diferentes operaciones que se han realizado para la implementación de la API, puesto que es lo primero que hemos establecido. Para ello, se ha tomado como punto de partida el diseño definido en la arquitectura REST. Las mejores prácticas indicadas en esta arquitectura están implícitas en los estándares HTTP.
Para muchos de nosotros diseñar una API puede sentirse como un arte. En este apartado vamos a indicar las reglas que se han decidido seguir para la definición de rutas, el modelado los diferentes recursos, en que colecciones se han agrupado, estados de las respuestas,
50
negociación de contenidos, operaciones imprescindibles por cada tipo de colección y middlewares necesarios para cumplir los requisitos.
Para empezar, los datos se agruparán en colecciones, cuyos nombres se van a representar mediante sustantivos en plural. Todos aquellos que estén representados en la base de datos con el mismo modelo de datos van a pertenecer a la misma colección. Tener en cuenta que, debido a la utilización de MongoDB, cada uno de los recursos será identificado por el identificador del documento “_id”. De tal manera que, para realizar operaciones de actualización o lectura de un recurso en concreto va a ser necesario el conocimiento de este identificador. En caso de querer realizar operaciones específicas sobre un recurso en concreto, se definirán controladores aplicados a la colección. Un ejemplo de este último caso podría ser “/componentesBVA”. Por otro lado, por cada una de las colecciones que represente un recurso se van a implementar operaciones de lectura, escritura, actualización y borrado (CRUD). Teniendo en cuenta que en las de lectura se permitirá pasar parámetros para filtrar entre los diferentes objetos representados en la base de datos, así como ordenación y búsqueda por contenido. En cuanto a las operaciones de escritura, devolverán la ruta al nuevo recurso, indicando el “_id” del nuevo documento creado. De este modo, se facilita al usuario la colección en la que se encuentra la información. Todas estas operaciones van a tener que manejar las posibles respuestas que se puedan presentar. En el conjunto de las operaciones se están tratando los siguientes estados de respuesta:
x 2xx. Respuesta estándar de una petición que ha sido recibida, aceptada y ejecutada correctamente, devolviendo los resultados esperados. Esta opción la encontraremos en todos los métodos desarrollados. 200 OK se utilizará para todos los métodos, a excepción del POST, utilizando 201 Created como código de respuesta.
x 4xx. Se refiere a errores del cliente, La solicitud puede contener sintaxis incorrecta o no puede procesarse. La intención de esta clase de códigos de respuesta es para casos en los que el cliente parece haber errado en la petición. En este caso, se usará 404 (controlar la existencia o no del recurso) y 400 (error de validación o el formato del id del documento incorrecto).
x 5xx. Se refieren a errores del servidor. Pueden generarse por un error en el propio servidor. Con el estado 500, controlaremos si el servidor falló al completar una solicitud aparentemente válida.
Para la negociación de contenidos, se ha utilizado MIME application/json, puesto que para la construcción de la API se quiere aceptar una entidad codificada con JSON desde el cuerpo de la petición. Todas las repuestas y mensajes de error generados, serán codificados siguiendo esta representación.
51
Otro de los principios básicos de REST es la el uso de SSL para la comunicación hacia las diferentes rutas del servicio. SSL garantiza una comunicación cifrada y además simplifica los esfuerzos de autenticación. Sin embargo, no se ha implementado de momento este punto, queda pendiente de realización en líneas futuras. Por el momento se está utilizando el protocolo HTTP. Todo esto no quita que se haya desarrollado middleware para la autenticación de usuarios, ofreciendo mayor seguridad y permisionado de los diferentes endpoints, condicionando a los usuarios la realización una operación de login para así obtener el JSON Token que va a ser necesario para el acceso a diferentes endpoints. Decir, que esta funcionalidad no está implementada del todo, únicamente el middleware que va a permitir realizar esta operación. Más adelante, cuando se indique que tipo de usuarios van a tener acceso se llevará a cabo este proceso.
Asimismo, el endpoint principal que se utilizará independientemente de la petición que se realice desde el lado cliente es “dashboard.com” seguido de un subdominio indicando la versión en la que se encuentra “dashboard.com/v1”. De esta forma, grandes cambios en el desarrollo del código de nuestro servicio Web no tienen que representar un problema para su posterior empleo, facilitando así, la velocidad a la hora de iterar y evitar peticiones inválidas desde rutas actualizadas. Adicionalmente, para indicar los diferentes endpoints destinadas a dar servicio al interfaz Web se va a definir el dominio /api donde se van a agrupar dichas operaciones. Teniendo en cuenta la información proporcionada, un ejemplo de una ruta a un servicio podría ser el siguiente: “http://dasboard.com/v1/api/components”. En este caso estamos accediendo a la colección de componentes, permitiendo la realización de una operación de lectura o escritura sobre la colección.
Por último y no menos importante, se seguirán las buenas prácticas en la documentación de los métodos, utilizando para ellos los estándares de JavaScript. Cada una de las operaciones indicará todas las opciones que admite para su ejecución o que elementos serán necesarios para el correcto funcionamiento.