Last modified: 2014-02-03 14:01:41 UTC
Currently API:Query automatically sorts pages alphabetically. So query like this http://en.wikipedia.org/w/api.php?action=query&prop=revisions&format=json&rvprop=content&export=&titles=Orange|Apple|Banana Will return pages in following (alphabetical) order: Apple, Banana, Orange I see a lot of cases when it's handy, but there are also cases, when you don't want API to sort results and would prefer it to return pages in order requested (e.g. Orange, Apple, Banana). I suggest, some kind of API key be added to query options, requesting NOT to sort results (e.g. nosort). If you need actual example, when sorting does more harm then good, I'm querying DjVu pages from Wikisource, and I'm requesting pages in following order: Book/99|Book/100|Book101, and response I get is Book/100, Book/101, Book/99. Sorting can be good, and can be bad, and we need an option to get results in order they were requested. I believe it shouldn't be hard to implement.
To apply limits and to allow query-continue to work the result of the database is always in sort order. Without a predefined order it is not possible to get the next batch, when needed. In your example there is no continue, but that is only known after receive the data from the database. In that case it could be possible to sort the result on the server. In my opinion it should be easier to sort the result on the client or to iterate over the given titles and get the part of the result instead of iterate over the result.
Thanks for sharing your idea. The bug title does not describe a bug but a solution or feature / new functionality. Hence setting priority to enhancement.
I'm marking this as WONTFIX for the reasons described in comment 1. Continuation requires that the database queries be sorted. If clients need the result pages in a particular order, they can easily enough pull the results into a local data structure and sort them there.
