New endpoint to list group members by ID only


#1

In order to add or delete a group member with the API, all you need is the user’s ID

/api/v1/groups/${groupId}/users/${userId}

It’s nice, simple and efficient.

However, when listing the members of the group, there is no way to retrieve only the user’s ID. The users endpoint at

/api/v1/groups/${groupId}/users

returns the full representation of every user of the group.

In large environments with lots of groups (200,000 users and 58,000 groups) this results in an extraordinary amount of bandwidth required to synchronize group members.

There would be great value in having a ‘userids’ endpoint in which to call that returns an array of user IDs only. eg

/api/v1/groups/${groupId}/userids

This will allow scripts and systems that maintain references between systems to keep everything synchronized in the most efficient way possible. To add, delete, or list members of the group, all you should need is the user id.

Some math to back this up;

Let’s say a conservative user profile is about 2KB in size. This includes the basic details and a few custom attributes. The membership request for a large group of 200,000 users would be 390MB in size. A medium size group of 50,000 users would be 97MB in size. Even a small group of 10,000 members is 19MB in size. It doesn’t take many groups for this to start adding up into the gigabytes range.

If we consider a user id-only endpoint, that only requires ~23 bytes per user id, that’s about 1% of the size of the full user representation. Our 200,000 member group response is now only 4.3MB in size. Our 50,000 member group response is only 1.1Mb in size

The full member endpoint is useful for UI use-cases, but for programmatic management of groups, its very inefficient.