[OASIS Issue Tracker] (ODATA-1228) Support non-batch mechanism for long URLs

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

Michael Pizzo created ODATA-1228:
------------------------------------

             Summary: Support non-batch mechanism for long URLs
                 Key: ODATA-1228
                 URL: https://issues.oasis-open.org/browse/ODATA-1228
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Bug
          Components: Protocol, URL Conventions
    Affects Versions: V4.01_CS01
         Environment: Proposed
            Reporter: Michael Pizzo
             Fix For: V4.01_CS02


From the early days of OData we have had issues with requests exceeding the maximum URL length for servers.

The typical response has been to use $batch, which passes the request in the body.  However, using $batch is a bit overkill for this common scenario, and has several drawbacks:
1) using $batch is non-intuitive and introduces extra complexity and concepts for executing a single request
2) the /$batch request and response must both be wrapped, with things like headers, request verbs, and response codes hidden within the payload.
3) the /$batch endpoint is at the root, which means that the request is not routed according the URL but the request body must be parsed in order to determine routing

Instead of relying on batch, we can define a /$query segment that can be applied to a resource path.  Clients POST to the URL, providing the query string in the body. For simplicity, we should make it an error to provide any query string in the request URL to the /$query endpoint.

The format of the querystring in the body is an interesting discussion.  One option is to provide it as a simple string, which would be the most consistent with the existing query string.  Alternatively, we could provide a JSON payload of name/value pairs for each query string option. The two are not mutually exclusive; the client could indicate through the content-type header which format they are using (applicaiton/text versus application/xml).

We could also explore other structured representations of certain query options. For example, we could provide an AST representation of the $filter query option that could be simpler and more efficient to build and parse than serializing as a string. 

The drawback to defining multiple formats is that services either need to support both, or clients need to check which format(s) are supported by the service.




--
This message was sent by Atlassian JIRA
(v7.7.2#77003)