To throw some context around our models: an organization has users (with different roles), and users have blog posts.
I have a use case where I need to populate two tables in our UI with post usage data by users in an organization (i.e. posts as in blog posts). One table shows a summary of the total post count for the entire organization grouped by the role of the user (e.g. admins, editors, and writers). The other table, though, would show all users and the post count for each one of them, regardless of their role.
However, this API endpoint/s will also be public and used by organization admins to determine post usage, so we want it to be as intuitive as possible.
We already have an endpoint that returns data about users (email, name, etc.)
The format is akin to:
{
current_page: 1,
per_page: 50,
next_page: 2,
previous_page: null,
total_pages: 3,
total_count: 150,
users: [
{
id: 1,
name: "John Doe",
email: "email@example.com",
...
},
...
]
}
The aggregated data we need is just the post count for an organization grouped by user roles, as well as the post count per user (for all users). That is, the number of posts that a user has published over a time period (which would be provided in the URL params).
We've bounced this idea for a second, and have come up with some alternatives, the one making more sense so far being serving data through one endpoint that allows for aggregating data based on defined aggregation patterns.
For example, we could do the following to get the information for the first table, which needs aggregated data for an entire organization:
# /usage/posts?from=&to=&aggregation=user_role
{
usage: {
admin: {
post_count: admin_posts.count,
published_post_count: admin_posts.published.count
},
editor: {
post_count: editor_posts.count,
published_post_count: editor_posts.published.count,
},
writer: {
...
}
}
}
Then for the second table, which needs to include all users in an organization and their post counts, we can do something along the lines of:
# /usage/posts?from=&to=&aggregation=user(default)
{
current_page: 1,
per_page: 50,
next_page: 2,
previous_page: null,
total_pages: 3,
total_count: 150,
usage: [
{
id: user.id,
post_count: user.posts.count,
email: user.email,
name: user.name,
role: user.role,
...
},
{
id: user.id,
post_count: user.posts.count,
email: user.email,
name: user.name,
role: user.role,
...
},
...
]
}
Does this payload structure seem intuitive? Not just for our own usage and to be able to populate our UI, but also for our users to fetch data from that they can use however they see fit.
I'd appreciate any feedback and thoughts!
Aucun commentaire:
Enregistrer un commentaire