Combinación RESTful y división del recurso

Question

Tengo un servicio REST que sirve la funcionalidad de Factura, por ejemplo, puedo crear, actualizar y eliminar una factura a través del servicio REST.

Sin embargo, ahora necesito tener la funcionalidad para dividir una factura en varias facturas nuevas, es decir, el método necesita crear x facturas basadas en una factura y luego eliminar la factura original en una transacción.

También necesito un método de fusión que haga lo contrario, es decir, varias facturas fusionadas en una sola.

¿Cómo puedo crear dicho arquitecto de la manera RESTful?

Answer 1

Tuvimos un problema similar en el que queríamos fusionar 2 recursos. Después de un largo debate, decidimos que un consumidor PUBLICARÍA un recurso de solicitud de fusión que contuviera los 2 recursos que se fusionarían. Luego, después de analizarlo, decidimos que no había necesidad de recursos completos tanto de origen como de destino y, en cambio, era suficiente con un POST de solo el identificador único. No hicimos la solicitud de fusión con solo las 2 ID en el cuerpo. Era más fácil representarlo en una URL, así que eso es lo que hicimos. La respuesta de la POSTING de una solicitud de fusión es el recurso fusionado.

supongo que no soy un gurú RESTO suficiente para decir que esto era una buena estrategia o no, pero para nosotros fue una solución sencilla, así que fuimos con él.

Answer 2

Cuando dice que desea implementar esta funcionalidad en "una transacción", supongo que ya ha determinado que debe combinar la generación de las nuevas facturas y la eliminación de la anterior, en una llamada API; cual es el enfoque correcto. Con los servicios web, usted querrá reducir las conversaciones y probablemente exista alguna lógica comercial sobre cómo esta funcionalidad generará las nuevas facturas y eliminará la anterior. Entonces asumo que cuando preguntas cómo diseñar esto de forma RESTful, te preguntas qué verbo HTTP usar (por ejemplo, GET, POST, PUT o DELETE) para este nuevo método API. Por lo general, estos verbos se asignan a operaciones de tipo CRUD de la siguiente manera:

• Crear -> poner
• Leer -> GET
• Actualización -> put
• Eliminar -> Eliminar

Entonces, qué verbo usar cuando su función crea y elimina registros. Una regla general con REST API es si no hay una asignación clara a CRUD y luego usa POST si hay un cambio en el estado del servidor y un GET si solo está devolviendo información que no cambia el estado del servidor. Entonces en este caso iría con un POST.

Si está buscando orientación adicional sobre cómo diseñar esto, sea más específico en lo que está buscando e intentaré ayudarlo.

Answer 3

me gustaría hacer algo similar,

POST /InvoiceSplitter?sourceInvoiceId=99 

y

POST /InvoiceMerger?sourceInvoiceIds=101,87,23,45