@Xveeder

Как спроектировать разные представления одной сущности REST?

Всем привет!

При проектировании REST-интерфейса у меня возникло некоторое искажение. Объясню на примере:

Есть энтрипойнт: [GET] api/entities

Этот энтрипойнт возвращает список сущностей и все работает отлично. Но вдруг, у меня возникла новая задача. Дело в том, что каждая сущность имеет связь с другими сущностями. По умолчанию, API возвращает сущности в том виде, в котором они присутствуют в таблице, например:

{
    id: 5,
    user_id: 32,
    task_id: 873
}


В новом роуте мне нужно, чтобы в ответ приходила структура, где эта сущность полностью развернута, например:

{
    id: 5,
    user: {
        id: 32,
        name: 'Alex'
    },
    task: {
        id: 873,
        status: 'done'
    }
}


Вопрос в том, как правильно именовать новый роут для нового искуственного ресурса. Какие варианты я вижу:

api/entities/full
api/full/entities // Этот вариант кажется не очень корректным, так как нарушает иерархию


Еще есть вариант использовать get-параметры или ключи в запросе, но кажется, что 1 маршрут должен соответствовать одному контроллеру, а не включать разветвленную логику запуска разных контроллеров одного уровня.

Словом, интересует логика правильного присвоения модификатора ресурса.
  • Вопрос задан
  • 49 просмотров
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы