Open carohadad opened 11 years ago
Agree with this, but can probably be added in a later version.
Suggest to postpone from 1.1/current release as we don't have sorting defined in this version; but agree with the recommendation by chadad
For the record, in http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api there's a nice example of how to address this issue. The relevant lines are:
"Sorting: Similar to filtering, a generic parameter sort can be used to describe sorting rules. Accommodate complex sorting requirements by letting the sort parameter take in list of comma separated fields, each with a possible unary negative to imply descending sort order. Let's look at some examples:
GET /tickets?sort=-priority - Retrieves a list of tickets in descending order of priority GET /tickets?sort=-priority,created_at - Retrieves a list of tickets in descending order of priority. Within a specific priority, older tickets are ordered first"
I like the idea of using "-" to imply descending order, it's easier to read and parse than the approach we were suggesting ("sort=priority:desc, created_at:asc").
+1 for -
Lol. plus one for minus here too.
On Jun 10, 2013, at 6:29 PM, Mike White notifications@github.com wrote:
+1 for -
— Reply to this email directly or view it on GitHub.
Hi all!
We found an issue with the specs of sorting criteria.
Let's say I want to sort by beds 'asc' and then by nurses 'asc'. According to the current specification, I should send this query:
/facilities.json?sortAsc=beds&sortAsc=nurses
Then the 'sortAsc' query key would be duplicated, and the way that's interpreted by default varies depending on your choice of language and/or framework. (You can take a look at a discussion on the topic at: http://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys).
In order to avoid this issue we suggest to change the specification so the query is performed in the following way in future versions of the API.
/facilities.json?sort=beds:asc,nurses:asc,numServices:desc (sorting precedence from left to right)
This would be interpreted as a plain string regardless of languages and frameworks. We think this is better because in general it's much easier to parse a string than to modify the default URI parsing behavior of the underlying framework.
And this way we can get around the limitation on sorting parameters.
Does this sound good to you?