Как мне обращаться с иерархиями объектов в RESTful API?
В настоящее время я разрабатываю API для существующего приложения PHP, и с этой целью исследую REST как разумный архитектурный подход.
Я считаю, что у меня есть разумное представление об основных концепциях, но я изо всех сил пытаюсь найти кого-нибудь, кто занимался бы иерархиями объектов и REST.
Вот в чем проблема ...
В бизнес-объекте [приложение] Иерархия у нас есть:
Users
L which have one-to-many Channel objects
L which have one-to-many Member objects
В самом приложении мы используем подход отложенной загрузки для заполнения объекта User массивами этих объектов по мере необходимости. Я считаю, что в объектно-ориентированных терминах это агрегация объектов, но я видел различные несоответствия именования и не хочу начинать войну из-за точного соглашения об именах.
А пока представьте, что у меня есть несколько слабо связанных объектов, которые я могу / не могу заполнять в зависимости от потребностей приложения.
С точки зрения REST, я пытаюсь выяснить, каким должен быть подход. Вот мое текущее мышление (учитывая только GET на данный момент):
Вариант 1 - полностью заполнить объекты: МИНУСЫ: объекты должны быть полностью заполнены (дорого)
Вариант 2 - заполнить первичный объект и включить ссылки на другие ресурсы объекта:
GET api.example.com/user/{user_id}
Прочитать объект пользователя (ресурс) и вернуть объект пользователя заполненные данные пользователя и два списка .
Каждый список ссылается на соответствующий (под) ресурс, т. Е.
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
вызов / channels вернет список каналов. ресурсы в форме (как указано выше):
api.example.com/channel/{channel_id}
ПЛЮСЫ: первичные ресурсы показывают, куда идти, чтобы получить субодинаты, но не то, что они есть (больше RESTful?), нет необходимости получать подчиненных заранее, генераторы подчиненных списков (/ каналы и / members) предоставляют интерфейсы (например, метод), делая ответ более сервисным.
МИНУСЫ: теперь требуется три вызова для полного заполнения объекта
Вариант 4 - (повторно) рассмотреть дизайн объекта для REST
Я повторно использую [существующую] иерархию объектов приложения и пытаюсь применить ее к REST - или возможно, более прямо, предоставьте ему интерфейс API.
Возможно, иерархия объектов REST должна быть другой, или, возможно, новое мышление RESTful обнажает ограничения существующего дизайна объекта.
Любые мысли по вышеизложенному приветствуются.
] Большое спасибо
Пол