Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-1052

Consider the "fragility" of server-driven paging

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: V4.0_OS
    • Fix Version/s: V4.02_WD01
    • Component/s: Protocol
    • Labels:
      None
    • Proposal:
      Hide

      Possibilities would include for the client to be able to:

      (1) Ask the server to return an error rather than send next-links.
      (2) Ask the server to use an exact page size, otherwise return an error (or perhaps this can just be done with top&skip, in addition to (1)).
      (3) Ask the server to only return next-links at the outermost level of response content (disable nested next-links).

      Minimally, if might turn out that "nested next-links" were never intended to be supported. If that is so, then at an absolute minimum, this must be clarified. At least that would limit the scope of "extra care" that must be taken by client implementors.

      Show
      Possibilities would include for the client to be able to: (1) Ask the server to return an error rather than send next-links. (2) Ask the server to use an exact page size, otherwise return an error (or perhaps this can just be done with top&skip, in addition to (1)). (3) Ask the server to only return next-links at the outermost level of response content (disable nested next-links). Minimally, if might turn out that "nested next-links" were never intended to be supported. If that is so, then at an absolute minimum, this must be clarified. At least that would limit the scope of "extra care" that must be taken by client implementors.

      Description

      Server-driven paging can make client applications "fragile", as follows...

      Suppose that a server doesn't support server-driven paging (or supports it only for responses over a certain response size that the client has never queried for).

      Now suppose that a client has been developed without regard for server-driven paging. That client may be easily "broken" (fail to receive all applicable response data) if:

      (1) The server is upgraded to support server-driven paging, or
      (2) Response sizes go over a threshold due to growth in the volume of data at the server.

      Now things can get worse, since depending on interpretation of the spec, next-links can appear at any level within a result, e.g.

      http://docs.oasis-open.org/odata/odata-json-format/v4.0/errata03/os/odata-json-format-v4.0-errata03-os-complete.html#_Toc453766645

      This means that clients have to mix parsing with network-level access, i.e. a client that wants to be sure to receive all of the requested data must be prepared to walk over the initial response "graph" (e.g. JSON result) issuing additional network requests to follow all next-links which may appear in the graph. This is such an onerous requirement that it is unlikely that many clients will properly implement it. The result: a "fragile" client which may silently fail to retrieve all relevant expected response content.

      Another case to consider is where a client uses a batch request to batch several queries (to avoid round-trips). This can be easily defeated by a server which may return next-links in each of the batched responses. The client may be unable to reduce round-trips as much as expected if many next-links are returned (or if the server uses a page size which is unreasonably small).

      The above difficulties with next-links suggest a redesign of server-driven paging may be warranted.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              evan.ireland.2 Evan Ireland
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: