Specify the sorting of resource listings#224
Conversation
7f2dc80 to
5c82420
Compare
samdbmg
left a comment
There was a problem hiding this comment.
Looks good overall - couple of thoughts inlined
| All endpoints will have a `reverse_order` query parameter, matching that which currently exists on the `/flows/{flowId}/segments` endpoint. | ||
|
|
||
| Datetime keys shall be sorted newest-first by default. | ||
| String keys shall be sorted ascending alphabetically by default. |
There was a problem hiding this comment.
Do we need to specify (or preferably, cite) a lexicographical ordering to avoid uncertainty for casing and numbers?
There was a problem hiding this comment.
I left this out because I think lexographical can often result in lower case being grouped and upper case being grouped, if I'm not mistaken. At least, how they are defined in programming languages differs. With the likes of Python requiring you to go as far a key such as sorted("This is a test string".split(), key=str.casefold) which may be just as un-clear in terms of how numbers/none alpha-numeric chars are handled. I felt stating "alphabetically" better conveyed sorting such that a is next to A without having to dig into the peculiarities of languages.
Co-authored-by: Sam Mesterton-Gibbons <sam.mesterton-gibbons@bbc.co.uk>
There was a problem hiding this comment.
Do we need to add the X-Paging-Reverse-Order header too to be consistent with the Segments endpoint?
Details
TAMS hasn't previously specified how resource listings should be sorted. This PR includes an ADR on options for how resource listings should be sorted.
Issue (if relevant)
GitHub Issue: #189
Jira: https://jira.dev.bbc.co.uk/browse/CLOUDFIT-5486
Related PRs
Submitter PR Checks
Reviewer PR Checks
Info on PRs
The checks above are guidelines. They don't all have to be ticked, but they should all have been considered.