[OASIS Issue Tracker] Commented: (CAMP-42) Spec should say how to limit/specify the scope of returned data

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

    [ http://tools.oasis-open.org/issues/browse/CAMP-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32238#action_32238 ] 

Tobias Kunze  commented on CAMP-42:
-----------------------------------

While I believe the use cases have merit, I am sceptic as to whether a full-blown query language should be part of this standard, mostly on two grounds:

1. Style. The purpose of REST is to standardize client-server communication on the lowest possible denominator, i.e. the passing of resource representations as opposed to executing parameterized function calls. This allows for a minimum of interdependence between clients and servers. The downside to this elegance is a very low degree of control and the potential of what may seem like an excess data transfer. Similarly, while reducing interdependence even further, HATEOAS adds to this by making clients to what may seem like excessive traversals in the URL space. However, since neither "excesses" seem too onerous to me, I believe they make for a poor argument to depart from REST and HATEOAS.

2. Topology. Why does the query language need to be executed server-side? The only reasons I can think of are a) to save on data transfers and b) to unburden clients from implementing such a language. However, large data transfers are quite efficient and standardizing on a single query language server-side has direct risks associated with it, such as viability, maturity, adoption, etc. of the language in question. The JAQL examples also read JSON from disk first, then execute the query in memory. I think everyone would agree that requiring the filesystem to implement JAQL would be going too far. And I believe requiring the server to implement it isn't much different.

Of the four main ways forward here,

1. Drop query languages server-side, i.e. leave them to clients to implement
2. Support query languages as extensions that implementations are free to offer
3. Standardize on a very small set of query operations such as "limit", "start", etc. that target very specifically the downsides mentioned above, i.e. data transfer size
4. Standardize on a full-blown, mandatory query language

my vote would go to #1 for now.

> Spec should say how to limit/specify the scope of returned data
> ---------------------------------------------------------------
>
>                 Key: CAMP-42
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-42
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Task
>          Components: Spec
>            Reporter: Alex Heneveld
>            Assignee: Alex Heneveld
>
> Currently the spec only dictates requests whose response is an entire Resource object.  These Resources could be very large however, and it is wasteful for everyone to send the entire object if, as will commonly be the case I expect, the client is only interested in a small piece of the Resource.
> This spec should define how a client can restrict a query to selected items of the Resource.  This should include:
> * filtering: selecting a specific key or restricting to a set of keys
> * pagination: selecting a specific element or range of elements (where a key's value is of type list)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira