RESTful way to create multiple elements in one request

Question

I am working on a small client program for collecting orders. I want to do this using the "REST (full)" method.

What I want to do:

Collect all order lines (product and quantity) and send the full order to the server

At the moment I see two options:

• Send each order line to the server: POST qty and product_id

Actually, I don’t want to do this because I want to limit the number of requests to the server, so option 2:

2. Collect all the order lines and immediately send them to the server.

How do I implement option 2? I have a few ideas: Wrap all order lines in a JSON object and send it to the server or use an array to place order lines.

Is it a good idea or good practice to implement option 2, and if so, how do I do it.

What is good practice?

Answer 1

I believe that another good way to approach this is to create another resource that represents your collection of resources. For example, imagine we have an endpoint, such as /api/sheep/{id} , and we can POST before /api/sheep to create a sheep resource.

Now, if we want to support bulk creation, we should consider the new flock resource in /api/flock (or /api/<your-resource>-collection if you lack a more meaningful name). Remember that resources do not need to map their databases or application models . This is a common misconception.

Resources are a higher-level view that is not related to your data. Working with a resource can have significant side effects, such as turning on a user alert, updating other related data, starting a long process, etc. For example, we could map the file system or even the unix ps command as a REST API.

I think it is safe to assume that working with a resource may also mean creating several other objects as a side effect.

Answer 2

Although bulk operations (such as batch creation) are important on many systems, they are not formally taken into account in the RESTful architecture style.

I found that the POSTing collection, as you suggested, basically works, but problems arise when you need to report crashes in response to such a request. Such problems are worse when there are numerous failures for various reasons or when the server does not support transactions. My suggestion for you is that if there is no performance problem, for example, when the service provider is on the local network (rather than the WAN) or the data is relatively small, it is worth sending 100 POST requests to the server. Keep it simple, start with individual queries, and if you have performance issues, try optimizing.

Answer 3

Facebook explains how to do this: https://developers.facebook.com/docs/graph-api/making-multiple-requests

Simple batch requests

The batch API accepts an array of logical HTTP requests represented as JSON arrays - each request has a method (the corresponding HTTP method GET / PUT / POST / DELETE, etc.), relative_url (part of the URL after graph.facebook.com), an additional array headers (corresponding to HTTP headers) and an optional element (for POST and PUT requests). The batch API returns an array of logical HTTP responses represented as JSON - each response has a status code, optional array headers and an optional object (which is a JSON encoded string).

Answer 4

Your idea seems valid to me. Implementation is a matter of your preference. You can use JSON or just parameters for this ("order_lines []" array) and

 POST /orders 

Since you are going to create more resources at a time in one action (order and its lines), it is important to check each of them and save them only if they all pass the test, i.e. You must do this in a transaction.

Answer 5

I assume it is better to send individual requests to a single connection . Of course your web server must support it

Answer 6

Recently, I struggled with this, and that's what I work for.

If the POST adding multiple resources succeeds, return 200 OK (I examined 201, but the user does not ultimately land on the created resource) along with a page that displays all the added resources, either in read-only mode, or in editable form. For example, a user can select and POST multiple images to a gallery using a form containing only one input file. If the POST request is completely completed, the user is provided with a set of forms for each created representation of the image resource, which allows them to specify more detailed information about each (name, description, etc.).

If it is impossible to create one or more resources, the POST handler cancels all processing and adds each individual error message to the array. Then, the 419 Conflict is returned, and the user is redirected to the 419 Conflict error page, which represents the contents of the error array, as well as the path back to the form that was submitted.

Answer 7

I believe Pipelining is the answer you need, which is described in the previous “One Connection” link.

Answer 8

You do not want to send HTTP headers for 100 order lines. You do not want to generate more requests than necessary.

Send the entire order in one JSON object to the server so that: server / order or server / order / new. Return what points to: server / order / order_id

Also consider using CREATE PUT instead of POST.