I find it a bit odd that I cannot retrieve a list of all groups and their members (and possibly admins) in a single API call. But maybe I’m doing things wrong? 
This is for an external application.
I can obtain a list of users, and I can obtain a list of groups, which is great. But if I want to figure out which users are members of each group, I need to iterate the groups, and make one additional API call per group to obtain the list of members. This seems unnecessarily expensive.
You can use this API/Rest in additional, but, yes, I understand it’s a little heavy.
http://stable27.local/ocs/v1.php/cloud/users/admin/groups
Where admin is the uid.
{
"ocs": {
"meta": {
"status": "ok",
"statuscode": 100,
"message": "OK",
"totalitems": "",
"itemsperpage": ""
},
"data": {
"groups": [
"admin"
]
}
}
}
Yes. I was about to add that to my post, but it still means iterating a list of either users or groups, and then getting groups for the user, or users for the group.
So if I have ten groups, thats a minimum of ten calls. If I have 100 users, that’s a minimum of 100 calls.
I can also quite easily see this turn into a throttling issue where I wouldn’t be allowed (and possibly for good reason) to issue that many requests to a given server.
I mean, don’t get me wrong, it’s great that the API and its endpoints is there, but sometimes it feels like many API endpoints (not just Nextcloud) return single entities, or information about a single entity. It would be so much easier to allow for an “all” construct.
In this case, the “all” construct would probably resolve to a rather fast query on the server using order by/group by and then toss it into a json structure 
Yes, I agree is not efficient 
I don’t know if Nextcloud plans to (re)create API/Rest foreach entity (Users, Groups, etc.) with additional items/entities.
Well, let’s hope one of their developers at some point realizes that this does need a re-think 
Thanks for your comments!
You’re welcome 