Структура полезной нагрузки JSON для агрегированных пользовательских данных из API - PullRequest
Новая
       38

Структура полезной нагрузки JSON для агрегированных пользовательских данных из API

0 голосов
/ 10 декабря 2018

Чтобы бросить некоторый контекст в наши модели: в организации есть пользователи (с разными ролями), а у пользователей есть сообщения в блогах.

У меня есть вариант использования, когда мне нужно заполнить две таблицы в нашем пользовательском интерфейсе постомданные об использовании пользователями в организации (т.е. сообщения, как в сообщениях в блоге).В одной таблице показана сводка общего количества сообщений для всей организации, сгруппированной по роли пользователя (например, администраторы, редакторы и писатели).Однако в другой таблице будут показаны все пользователи и количество сообщений для каждого из них, независимо от их роли.

Однако эта конечная точка / точки API также будет общедоступной и будет использоваться администраторами организации для определения должностииспользования, поэтому мы хотим, чтобы он был максимально интуитивно понятным.

У нас уже есть конечная точка, которая возвращает данные о пользователях (электронная почта, имя и т. д.)

Формат похож на: 

{
  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",
      ...
    },
  ...
  ]
}

Агрегированные данные, которые нам нужны, это просто количество сообщений для организации, сгруппированной по ролям пользователей, а также количество сообщений для каждого пользователя (для всех пользователей).То есть количество постов, которые пользователь опубликовал за определенный период времени (что будет указано в параметрах URL).

Мы отбросили эту идею на секунду и предложили несколько альтернативтот, который имеет больше смысла, пока обслуживает данные через одну конечную точку, которая позволяет агрегировать данные на основе определенных шаблонов агрегирования.

Например, мы могли бы сделать следующее, чтобы получить информацию для первой таблицы, которая нуждается вагрегированные данные для всей организации: 

# /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: {
      ...
    }
  }
}

Затем для второй таблицы, в которую необходимо включить всех пользователей в организации и их количество сообщений, мы можем сделать что-то вроде: 

# /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,
      ...
    },
    ...
  ]
}

Эта структура полезной нагрузки кажется интуитивно понятной?Не только для нашего собственного использования и для возможности наполнения нашего пользовательского интерфейса, но и для того, чтобы наши пользователи могли получать данные, которые они могут использовать, какими они считают нужным.

Буду признателен за любые отзывы и мысли!

...