You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the document we need to add a lot more clarity around what content is returned based on what type of query. My proposal would be:
If there are is no added_after or added_before like filter than the results should be the newest ones in the collections sorted in reverse order (not sure on the sort order). Meaning, if you have 100 records, 0-99, and you limit the results to 10 records. You should get records 99-90 or 90-99 depending on which sort order we decide on.
If you have an added_after or added_before then it should just start at these points. I am once again, not 100% sure on the sort order for each of these. But we should be consistent as much as possible so that a client can have a predictable interaction with the server.
The text was updated successfully, but these errors were encountered:
We discussed this at the F2F and decided that it would be the oldest records first. We need to add some clarifying text to help implementers understand this.
Substance-wise this seems fine. It was a mistake to not make a determinative order.
In terms of text, I don't think "MUST return the oldest records first" is precise enough. "Oldest" needs to be more clearly defined, and "first" is kinda meaningless...I think what you're getting at is the sort order for records as they get paginated is by date added in ascending order.
The following text was added to section 3.4 added_after to try and resolve this issue:
If no added_after URL query parameter is provided, the server MUST return the oldest records matching the request first. For example, if a server has 100 records (0-99) and limits requests to 10 records at a time and a client makes a request without an added_after URL query parameter, the server would start at record 0 looking for a match and work its way up from oldest to newest finding 10 records that matched the request.
In the document we need to add a lot more clarity around what content is returned based on what type of query. My proposal would be:
If there are is no added_after or added_before like filter than the results should be the newest ones in the collections sorted in reverse order (not sure on the sort order). Meaning, if you have 100 records, 0-99, and you limit the results to 10 records. You should get records 99-90 or 90-99 depending on which sort order we decide on.
If you have an added_after or added_before then it should just start at these points. I am once again, not 100% sure on the sort order for each of these. But we should be consistent as much as possible so that a client can have a predictable interaction with the server.
The text was updated successfully, but these errors were encountered: