Плоский REST API (без вложенных отношений)

Question

Не по теме / Дублирование

• Многие асинхронные вызовы против одного вызова API
• Множество небольших запросовСравнение с несколькими большими запросами (разработка API)
• Разработка API REST: несколько вызовов против одного вызова API

ОРИГИНАЛ

Это хорошая идея?

Например:

// http://example.org/api/posts

[
  {
    "title": "Title one",
    "user_id": 1
  },
  {
    "title": "Title two",
    "user_id": 1
  },
  {
    "title": "Title three",
    "user_id": 2
  }
]

И затем сделать еще один запрос:

// http://example.org/api/users?filters={ids: [1, 2, ...]}

[
  {
    "id": 1,
    "name": "John"
  },
  {
    "id": 2,
    "name": "Vanessa"
  }
]

PROs

1. Простой дизайн REST API (плоский)
2. Более простой код на стороне клиента (нет normalizr / уже "нормализован")
3. Меньше издержек на конечную точку на сервере (нет необходимости загружать отношения)
4. Нет «дублированного» ресурса HTTP, загруженного между разными конечными точками (неизбежно)
5. Нет повторяющихся объектовданные внутри данного отклика конечной точки (меньшая полезная нагрузка) - Пример: выше, user = 1 (Джон) вложенные данные будут появляться дважды в /posts ответ

CONs

1. Больше HTTP-запросов к серверу - хотя это можно было бы облегчить с помощью хорошей (и более простой) стратегии кэширования
2. GraphQL (более новая технология) не поддерживает простые ответы

Примечание : Можно также рассмотреть сочетание двух подходов.

ВОПРОС

Неужели так плохо попадать на сервер с большим количеством запросов VSменьше запросов, но больше ответов на полезную нагрузку?