В настоящее время я разрабатываю API для существующего PHP-приложения и с этой целью исследую REST как разумный архитектурный подход.

Я полагаю, что у меня есть достаточное понимание ключевых понятий, но я изо всех сил пытаюсь найти кого-нибудь, кто занимался иерархиями объектов и REST.

Вот проблема ...

В иерархии бизнес-объектов [application] мы имеем:

Users 
 L which have one-to-many Channel objects
 L which have one-to-many Member objects

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

А пока рассмотрим, что у меня есть несколько слабо связанных объектов, которые я могу / не могу заполнять в зависимости от потребностей приложения.

С точки зрения REST, я пытаюсь выяснить, каким должен быть подход. Вот мое текущее мышление (учитывая GET только на данный момент):

Вариант 1 - полностью заполнить объекты:

GET api.example.com/user/{user_id}

Прочитайте объект User (ресурс) и верните объект User со всеми возможными объектами Channel и Member, предварительно загруженными и закодированными (JSON или XML).

ПРОФИ: уменьшить количество объектов, не требуется обход иерархий объектов
Минусы: объекты должны быть полностью заселены (дорого)

Вариант 2 - заполнить первичный объект и включить ссылки на другие ресурсы объекта:

GET api.example.com/user/{user_id}

Прочитайте объект User (ресурс) и верните объект User заполненные данные пользователя и два списка.

Каждый список ссылается на соответствующий (под) ресурс, т.е.

api.example.com/channel/{channel_id}
api.example.com/member/{member_id}

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

ПРОФИ: клиент может выбрать загрузку подчиненных или иным образом, лучшее разделение объектов как ресурсов REST
Минусы: дальнейшая поездка требуется, чтобы получить вторичные ресурсы

Вариант 3 - включить рекурсивное извлечение

GET api.example.com/user/{user_id}

Прочитайте объект User и включите ссылки на списки подобъектов, т.е.

api.example.com/user/{user_id}/channels
api.example.com/user/{user_id}/members

вызов / channel вернул бы список ресурсов канала в форме (как указано выше):

api.example.com/channel/{channel_id}

PROS: первичные ресурсы раскрывают, куда идти, чтобы получить субодинаты, но не то, чем они являются (более RESTful?), Нет необходимости получать подчиненные заранее, генераторы списка подчиненных (/ каналы и / члены) предоставляют интерфейсы (метод, подобный), создающий ответ больше сервис нравится.
Минусы: теперь нужно три вызова для полного заполнения объекта

Вариант 4 - (повторно) рассмотреть проектирование объекта для REST

Я повторно использую [существующую] иерархию объектов приложения и пытаюсь применить ее к REST - или, возможно, более напрямую, предоставить интерфейс API к ней.

Возможно, иерархия объектов REST должна быть другой, или, возможно, новое мышление RESTful выявляет ограничения существующего дизайна объектов.

Любые мысли по поводу вышеизложенного приветствуются.

Большое спасибо

Павел