Suppose I want to adhere to your advice and not return “associative arrays” in an API response. But the structure of the collection is clearly as with mentioned connections: An ID string and an object of always the same structure containing attributes of the identified thing.
So I should always use a format like this?
{
"interestingThings": [
{
"thingId": "abc",
"stuffs": [1, 2, 3, 4]
},
{
"thingId": "xyz",
"stuffs": [3, 4, 5, 6]
}
]
}
Or just skip the outer object and return a collection (array) directly? Example: GET /rest/events — Syncthing v1 documentation
What I previously thought would be nicer to consume (because we can do direct lookups by ID) is the following:
{
"abc": {
"stuffs": [1, 2, 3, 4]
},
"xyz": {
"stuffs": [3, 4, 5, 6]
}
}
Of course, if there is only the single stuffs attribute, its value could be used directly without wrapping in another object. Provided it’s clear from the endpoint name what “stuff” we are getting:
{
"abc": [1, 2, 3, 4],
"xyz": [3, 4, 5, 6]
}
Examples are GET /rest/cluster/pending/devices — Syncthing v1 documentation (which I added without knowing any better) and GET /rest/system/connections — Syncthing v1 documentation mentioned here (which I erroneously took as inspiration).
Implementing the first style above means to find out if the tuple ("abc", 3) is among the results, I need to walk every entry and compare both thingId and search in the stuffs attribute. Or rearrange the results into nested objects client-side after retrieving.
What I’d like to do in this case would be the equivalent to Python’s found = ("abc", 3) in results or at the least found = 3 in results["abc"]. Ideally without burning cycles needlessly on the client side when the generating Go code already used efficient maps internally.
