Te sugerimos que pruebes esta resolución en un entorno controlado antes de enviarlo a producción, saludos.
Solución:
He leído muchos artículos sobre REST en Internet.
Según lo que veo aquí, realmente necesitas ver al menos una de las charlas de Jim Webber sobre REST y DDD
- Descanse en la práctica
- Diseño controlado por dominio para sistemas RESTful
Pero, ¿qué hacer con el resto de casos de uso?
Ignore la API por un momento: ¿cómo lo haría con los formularios HTML?
Presumiblemente tendrías una página web que presenta una representación de Deal, con un montón de enlaces. Un enlace te llevaría al HoldDeal formulario, y otro enlace lo llevaría al ChangePrice forma, y así sucesivamente. Cada uno de esos formularios tendría cero o más campos para completar, y cada uno de los formularios se publicaría en algún recurso para actualizar el modelo de dominio.
¿Publicarían todos en el mismo recurso? Quizás, quizás no. Todos tendrían el mismo tipo de medio, por lo que si todos estuvieran publicando en el mismo punto final web, tendría que decodificar el contenido en el otro lado.
Dado ese enfoque, ¿cómo implementa su sistema? Bueno, el tipo de medio quiere ser json, según sus ejemplos, pero realmente no hay nada de malo en el resto.
1) Usa verbos:
Esta bien.
¡Pero! Los verbos no se pueden usar en la URL (en la teoría REST).
Mmm no. REST no se preocupa por la ortografía de sus identificadores de recursos. Hay un montón de mejores prácticas de URI que afirman que los verbos son malos, eso es true – pero eso no es algo que se siga de REST.
Pero si las personas son tan quisquillosas, nombre el punto final del comando en lugar del verbo. (es decir, “mantener” no es un verbo, es un caso de uso).
Utilice 1 solicitud PUT para todas las operaciones:
Honestamente, ese tampoco está mal. Sin embargo, no querrá compartir el URI (debido a la forma en que se especifica el método PUT), pero use una plantilla donde los clientes puedan especificar un identificador único.
Aquí está el meollo: está creando una API sobre los métodos HTTP y HTTP. HTTP está diseñado para transferencia de documentos. El cliente le entrega un documento que describe un cambio solicitado en su modelo de dominio, y usted aplica el cambio al dominio (o no) y devuelve otro documento que describe el nuevo estado.
Tomando prestado del vocabulario CQRS por un momento, está publicando comandos para actualizar su modelo de dominio.
PUT /commands/commandId
'deal' : dealId
'action': 'HoldDeal',
'params': 'reason': 'test'
Justificación: está poniendo un comando específico (un comando con un Id específico) en la cola de comandos, que es una colección.
PUT /rest/version/deals/dealId/commands/commandId
'action': 'HoldDeal',
'params': 'reason': 'test'
Sí, eso también está bien.
Eche otro vistazo a RESTBucks. Es un protocolo de cafetería, pero toda la API solo pasa pequeños documentos para hacer avanzar la máquina de estado.
Diseñe su api de descanso independientemente de la capa de dominio.
Uno de los key conceptos de diseño impulsado por dominios es acoplamiento bajo entre sus diferentes capas de software. Entonces, cuando diseña su api de descanso, piensa en la mejor api de descanso que podría tener. Luego, el rol de la capa de aplicación es llamar a los objetos de dominio para realizar el caso de uso requerido.
No puedo diseñar su api de descanso para usted, porque no sé qué está tratando de hacer, pero aquí hay algunas ideas.
Según tengo entendido, tiene un recurso de trato. Como dijiste, la creación / eliminación es fácil:
- POST / resto / versión / ofertas
- BORRAR / resto / versión / ofertas / id.
Entonces, desea “mantener” un trato. No sé qué significa eso, tienes que pensar en lo que cambia en el recurso “Deal”. ¿Cambia un attribute? Si es así, simplemente está modificando el recurso Deal.
PUT / rest / version / deals / id
...
held: true,
holdReason: "something",
...
¿Agrega algo? ¿Puede tener varias retenciones en una oferta? Me suena que “mantener” es un sustantivo. Si es feo, busque un sustantivo mejor.
PUBLICAR / descansar / versión / ofertas / id / retenciones
reason: "something"
otra solución: olvídese de la teoría REST. Si cree que su api sería más clara, más eficiente, más simple con el uso de verbos en la URL, entonces hágalo. Probablemente puedas encontrar una manera de evitarlo, pero si no puedes, no hagas algo feo solo porque es la norma.
Mire la API de Twitter: muchos desarrolladores dicen que Twitter tiene una API bien diseñada. ¡Tadaa, usa verbos! ¿A quién le importa, siempre que sea genial y fácil de usar?
No puedo diseñar su api para usted, usted es el único que conoce sus casos de uso, pero diré nuevamente mis dos consejos:
- Diseñe el resto de la API por sí mismo y luego use la capa de aplicación para llamar a los objetos de dominio apropiados en el orden correcto. Para eso está exactamente la capa de aplicación.
- No sigas las normas y teorías a ciegas. Sí, debe intentar seguir las buenas prácticas y normas tanto como sea posible, pero si no puede, déjelas atrás (después de una cuidadosa consideración, por supuesto)
El artículo Exponer CQRS a través de una API RESTful es un enfoque detallado que aborda su problema. Puede consultar la API del prototipo. Algunos comentarios:
- Es un enfoque sofisticado, por lo que es probable que no necesite implementar todo el contenido del artículo: la concurrencia de Event Sourcing a través de ETag de HTTP y If-Match es una característica tan “avanzada”
- Es un enfoque obstinado: el tipo de comando DDD se envía a través del encabezado del tipo de medio, no a través del cuerpo. Personalmente, lo encuentro interesante … pero no estoy seguro de implementarlo de esta manera.