El PUT siempre debe ser sobre el ID del registro, si la fecha es el ID no debería de marcar error, ya que le estás indicando que actualiza exactamente ese registro, pero si lo hace sobre cualquier otro campo que no es el ID, no debería de permitirlo. En tu caso, si la fecha no es el ID y lo permite, estamos en un mal diseño del servicio

Nosotros estamos teniendo un problema en la integración con un sistema a de terceros. Es una aplicación de gestión de citas. El problema es que si lanzamos un PUT de una cita donde mantenemos la fecha y hora de la cita, pero cambiamos por ejemplo un comentario del cliente, el sistema nos dice que el hueco de cita está ocupado (está detectando a la propia cita).

¿Es correcto este comportamiento en tu opinión?

Gracias y un saludo.

Lo que dices es correcto, lo que pasaría aquí es que cuando el 1° microsrvicio envíe por segunda vez el mismo UUID, el segundo servicio responderá que ya existe un registro con ese UUID, por lo que el primero ahora tendrá que consultar el registro creado por medio de ese UUID para responderlo.

Gracias!

El problema con el Bus es que negará el paso del request, lo que puede implicar que el primer request nunca llego al destinarario o no lo proceso correctamente, por lo que el bus asumirá que si y no permitirá el envio nuevamente.

Usa el UUID, cuando crees el pedido, le asignas el UUID, y ese lo envías al otro sistema, así si envian más de una ves ese pedido, lo podrás detectar.

No hay de que amigo, la idea es poder ayudar

En algunos escenarios, es necesario limitar los campos que pueden ser actualizados en un recurso, por regla de negocio. Supongamos que el nombre del comprador no se puede editar una vez realizado el pedido, por lo que un nuevo pedido no sería igual que una edición de un pedido. ¿Cómo se puede manejar ese escenario ya que en el ejemplo estas usando PUT para ambas acciones?. Saludos y muy buen artículo.