Traffic Ops GET /api/*/cdns should be sorted alphabetically by name by default

[rawlinp]

When clicking the snapshot button (the camera icon in the top right) in Traffic Portal, it shows the list of CDNs to choose from. Today, these CDNs appear to be sorted ascending by their numerical ID rather than alphabetically by their name. With a high number of CDNs to choose from, it would be easier to sift through the list alphabetically.

The CDN table (viewed by clicking the "CDNs" tab on the left) should also be sorted alphabetically by name. This appears to be a minor regression from the Perl TO API implementation which sorted by name by default (if no other orderby param is specified in the request URL): https://github.com/apache/trafficcontrol/blob/master/traffic_ops/app/lib/API/Cdn.pm#L34

[dangogh]

actually, I used to agree, but I've changed my mind and disagree.. a client should not be dependent on the order items are returned. If it has the need for them to be ordered a specific way, it should do so itself. In the case of the portal, it's easy enough to sort them when the cdn list is retrieved. We do have precedent for other types (I think servers are sorted), but we shouldn't try to do that going forward..

[dangogh]

in other words, I think this should be against the portal and not traffic ops

[rawlinp]

Yeah, I'm just thinking it's a minor change in behavior from the Perl implementation. Really, I think TP should be sending the ?orderby=name qparam in its request to TO to explicitly request that ordering. If you think this minor change in behavior is ok then I can get on board with that, and we can just fix the API request in TP.

[rob05c]

+1 on putting it in the Portal, not the API

IMO sorting shouldn't be part of an API. It's trivial for clients to do, and it reduces the scalability of the server. Sometimes it's trivial for the server to do, sometimes it's expensive. If it's expensive, it means that for n clients, the server has to do O(n) work, where the work for the client is O(1). And the client code is trivial as well, vals = http.Get(url); vals = sort(vals). IMO there's simply no good reason for clients to need the server to sort, and there's a potentially very good reason for the server not to.

[rawlinp]

I think we are getting into a much broader discussion about API 2.0. Currently most of our 1.x endpoints support server-side ordering, and I don't think we should rip that out of the 1.x endpoints. If we feel strongly that API 2.0 shouldn't support server-side ordering, then that's a discussion we should have on the mailing list about API 2.0 at a good time.

For this specific issue, I don't really care strongly if the sorting is done client-side or server-side, but I also don't think we should be worried about server-side sorting of CDNs affecting the scalability of TO. I would merge a TP PR that did the sorting either way.

[ocket8888]

I think the API should impose some order on the results it returns. Whether or not it's configurable via e.g. an orderBy query parameter is something I don't feel strongly about, but when things cannot be guaranteed to have any specific order it means that two requests to the same endpoint with the same TODB dataset cannot be guaranteed to have the same response, which harms testability. Imposing a specific ordering would eliminate a full third of the use case of my PR #3478