RESTful merging and sharing of resources

Question

I have a REST service that services Invoice features, for example, I can create, update and delete accounts through the REST service.

However, now I need to be able to split the invoice into several new invoices, i.e. To do this, create x invoices based on one invoice and then delete the original invoice in one transaction.

I also need a merge method that does the opposite, i.e. Multiple invoices combined into one.

How to create such a RESTful project?

Answer 1

We had a similar problem when we wanted to combine 2 resources. After much debate, we decided that the consumer would use a merge request resource containing two resources to combine. Then, looking at this, we decided that there was no need for either the full source or the target resource, and instead, a POST with only a unique identifier was enough. We did not make a merge request with only 2 identifiers entering the body. It was easier to represent in the URL so that we did. The response from a POSTing merge request is a combined resource.

I think I'm not a REST guru enough to tell you that it was a good strategy or not, but for us it was a simple solution, so we went with him.

Answer 2

When you say that you want to implement this function in a "single transaction", I assume that you have already determined that you should combine the creation of new invoices and the removal of the old into a single API call; which is the right approach. With web services, you want to reduce chatter, and there are probably some business logic on how this feature will generate new accounts and delete old ones. Therefore, I assume that when you ask how to do this in RESTful, you are wondering which HTTP verb to use (i.e. GET, POST, PUT or DELETE) for this new API method. Typically, these verbs display CRUD operations as follows:

• Create → POST
• Reading → GET
• Update → PUT
• Delete → DELETE

So which verb to use when your function creates and removes entries. The general rule with the REST API is if there is no clear mapping to CRUD, then use POST if there is a change in server status and GET if you simply return information that does not change the server state. So in this case, I would go with POST.

If you are looking for additional architectural recommendations, please be more specific about what you are looking for and I will try to help.

Answer 3

I would do something like

POST /InvoiceSplitter?sourceInvoiceId=99 

and

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