The GET scenario is better served by returning Accepted in the batch an allowing the client to fetch as they are available. For changesets, the results are required to be atomic so the changeset cannot return success or failure until all of the statements within it complete, so there is still value in allowing the service to reorder statements within a changeset.

I do not want to deny the service the right to reorder statements within a changeset.

My concern is about the number of things a client has to learn in order to submit a batch request and understand its result.

Previously these were three things:

• wrap multiple requests into a batch request
• unwrap a batch response into multiple responses
• correlate individual requests and responses BY SEQUENCE

The current proposal increases this to four things:

• wrap multiple requests into a batch request
• unwrap a batch response into multiple responses
• correlate individual requests and responses on the first level BY SEQUENCE
• correlate individual requests and responses on the second level (within changesets) BY CONTENT-ID

My proposal is to get this back down to three things:

• wrap multiple requests into a batch request
• unwrap a batch response into multiple responses
• correlate individual requests and responses BY CONTENT-ID

Agreed that the client should always specify Content-ID within the changeset and should rely on the returned Content-ID to correlate responses. We should not add the additional burden on the client or server to correlate requests within a changeset by sequence. This allows the server to re-order related items within a changeset in order to execute the set of items that make up a single transaction, and still stream results.

The server has no transactional need to re-order the items within the batch; each separate item within a batch is done as a separate atomic transaction. If these are executed asynchronously they should return 202 Accepted, rather than rely on the server to serialize if and how the individual requests are completed, blocking until a next result is available or returning a partial batch.

Let's start from where we agree and go one little step further:

The client should always specify Content-ID and should rely on the returned Content-ID to correlate responses.

No assumptions about ordering in the response.

Old Proposal:

Clients SHOULD specify a content-id header for each request within a changeset.
[MikePizzo: it might be simpler if we just always require the client to specify a content-id; it isn't hard to do and reduces the cases we have to define).
Services MUST return the specified content-id (if any) in the response.
Services MAY process requests within a changeset in any order.
Services MAY return results within the changeset in any order if and only if the client specified a content-id for each request part.
[MikePizzo: I would change the above rule to not depend on whether the client specifies a content-id for each request part]
[Ralf Handl: then the client MUST specify the content-id, otherwise it will not be able to interpret the response. And I really feel bad about making things harder for ALL clients just to make things easier for SOME services.]
[MikePizzo: agree that it is simpler if the client always specifies content-id and correlates requests w/in a changeset to responses according to that content-id; we should not require services to have dual logic depending on whether or not content-ids are provided. I actually think correlating requests within a changeset by id is straightforward to for the client, since the changeset is atomic and all values will be returned prior to processing the next statement in the batch.]
Services MUST return a response for each request, or a single error for the changeset.