Improve dstore/Request flexibility with various server-side approaches

[dylans]

As a follow-up to #104, we've received a few requests recently for how to use dstore where the server's model for how it handles data doesn't match with the assumptions that dstore makes.

One such request is: "Stores that support query string parameters for pagination rather than HTTP headers (I found this to be the most unusual thing about dojo; changing all my web services to suit would not be fun at all)"

Another was fairly significant confusion that results from trying to connect dstore with Django (though in this case the user may have been doing several unusual things): https://stackoverflow.com/questions/30603306/how-do-i-connect-a-django-rest-framework-json-query-result-to-dgrid-ondemandgrid

I think the best suggestion I have is that we take a look at a variety of popular frameworks for returning RESTful data, and see what options we need to provide to make it very easy for people to connect dstore to common server-side approaches for exposing data.

[kfranqueiro]

I'm assuming this is focused on dstore/Request? The title is vague.

dstore/Request does support query string parameters for ranges, through rangeStartParam and rangeCountParam.

However, there are a few annoyances and things it doesn't support changing (which I mentioned in #104):

• While it does support rangeStartParam and rangeCountParam, these default to blank, and so does useRangeHeaders... which leaves the default logic at adding a limit(count,start) parameter to the query string. Do any server frameworks besides persevere support this? I'm divided on what the default should be (maybe range headers like dojo/store), but it seems like today's default is the minority case.
• It supports receiving an object with an array on an items property rather than a top-level array, but the name items isn't configurable
• It supports inspecting a total property if it receives an object instead of inspecting the response's Content-Range header for the total number of items, but the name total isn't configurable

One unusual thing mentioned in that SO question is that the OP has a service which expects to receive page numbers rather than start and count - in which case start and count are calculated based on the page numbers. This isn't really compatible with the store API (or more specifically, its consumers) in general, since the API expects to deal in discrete start/count values, and thus excess data would need to be fetched if this were to be resolved from start/count to page requests.

[kfranqueiro]

It occurs to me that you might be able to get away with extending the parse method for the purpose of customizing how items are retrieved. However, it seems like total is still inextricably bound to the original data returned. The asymmetry there between how the items and total are resolved (how one involves calling parse and one doesn't) seems very odd to me, and perhaps I'm not reading into it entirely correctly...