[OASIS Issue Tracker] (ODATA-1350) OData V2 required continue-on-error style batch responses, V4 makes it optional for servers (due to use of Prefer)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Evan Ireland created ODATA-1350:
-----------------------------------

             Summary: OData V2 required continue-on-error style batch responses, V4 makes it optional for servers (due to use of Prefer)
                 Key: ODATA-1350
                 URL: https://issues.oasis-open.org/browse/ODATA-1350
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Improvement
          Components: Protocol
    Affects Versions: V4.0_OS
            Reporter: Evan Ireland


OData V2 spec for batch responses (Example 2) shows a response with multiple errors. OData V2 didn't have a continue-on-error preference to obtain this, it was just assumed that a batch could have multiple requests that were able to fail and the client would find out about all the failures.

For V4 we have Prefer (odata.continue-on-error) but it is opt-in, and optional for the server to support.

V2 clients had certainty that a server supporting batches would be able to return a single response with all parts (whether or not an error had occurred).

V4 clients no longer have that certainty, which from a performance perspective (in the presence of errors) is unsatisfactory. If a client sends a lot of GET requests that might return 404, they might only get one 404 response (batch response is truncated at the first error). Then they needs to resubmit the tail end of the batch. Time/space complexity is proportional to E*N*L, where E is the number of errors in the batch and N is the size of the batch request payload and L is the per-request latency.

We have clearly lost an important performance characteristic (clients having certainty about the cost of a batch of requests some of which can fail).

How can we get it back?

Perhaps we can make continue-on-error mandatory for servers to support if they support batches at all.




--
This message was sent by Atlassian Jira
(v8.3.3#803004)