Как я должен иметь дело с иерархиями объектов в RESTful API?
В настоящее время я разрабатываю 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 выявляет ограничения существующего дизайна объектов.
Любые мысли по поводу вышеизложенного приветствуются.
Большое спасибо
Павел