Es igual que el Query REST Controller, pero tiene una gran diferencia, y es su intención.
Especificaciones
Tiene una complejidad de 2 en casos normales.
Su principal intención, es alterar el estado de uno o varios elementos de nuestro Domain.
Si desglosamos sus características. Tiene varios verbos HTTP que acepta, cada uno cumple una petición diferente a su intención principal. “POST” representa la petición de crear un elemento. “PUT” y “PATCH” lo modifican, y “DELETE”… pues eso… lo elimina. Cumple el estándar REST y representa los datos que el User envía buscando modificar información. Con lo que su intención clara es modificar el estado del Domain.
Es parecido al Query REST Controller, sólo se relaciona con el User, Privileged user, External system y el Command.
Como observaciones adicionales podemos destacar que como vamos a modificar uno o varios elementos, la transaccionalidad seá necesaria, pero lo veremos en la carta adecuada. En ocasiones, no espera una respuesta del Domain. Simplemente asume que ha ido bien y devuelve un estado HTTP de tipo 2XX.
¿Qué valor me aporta implementar un Command REST Controller?
Aporta el mismo valor que cualquier carta de tipo Controller
- Como punto de entrada interpreta la petición y lo transforma a un mensaje que entiende el dominio (un DTO).
- En este punto, podemos establecer las reglas principales a nivel de si una petición es válida, e incluso aspectos extra de seguridad de acceso o gestión de errores controlados… lo que vienen siendo responsabilidades que recaen fuera del dominio.
- También podemos controlar en qué formato vamos a devolver la Response al peticionario.
¿Cómo se expresa esta carta en el mundo real?
Como indica el icono de arriba a la izquierda, corresponde a una clase.
|
|