Как мне работать с иерархиями объектов в RESTful API?

Нет причин не комбинировать их.

• api.example.com/user/{user_id} - вернуть представление пользователя
• api.example.com/channel/{channel_id} - вернуть представление канала
• api.example.com/user/{user_id}/channels - вернуть список представлений каналов
• api.example.com/user/{user_id}/channel_list - вернуть список идентификаторов каналов (или ссылки на их полные представления, используя указанные выше ссылки)

В случае сомнений подумайте о том, как вы могли бы отображать данные пользователю-человеку без проблем с «API»: пользователю нужны как индексные страницы ({user_id}/channel_list), так и полные просмотры ({user_id}/channels).

Как только вы это сделаете, просто поддержите JSON вместо (или в дополнение к) HTML в качестве формата представления, и у вас будет REST.

Лучший совет, который я могу дать, - это не думать о REST api как о раскрытии ваших объектов. Создаваемые вами ресурсы должны поддерживать нужные вам варианты использования. При необходимости вы можете создать ресурсы для всех трех вариантов:

api.example.com/completeuser/{id}
api.example.com/linkeduser/{id}
api.example.com/lightweightuser/{id}

Очевидно, мои имена немного бестолковые, но на самом деле не имеет значения, как вы их называете. Идея состоит в том, что вы используете REST api для наиболее логичного представления данных для конкретного сценария использования. Если существует несколько сценариев, при необходимости создайте несколько ресурсов. Мне нравится думать о своих ресурсах как о моделях пользовательского интерфейса, а не о бизнес-объектах.

Я бы порекомендовал Restful Obects, который является стандартом для демонстрации спокойных

Идея Restful Objects заключается в предоставлении стандартного универсального интерфейса RESTful для объектных моделей предметной области, предоставления представления их структуры с помощью JSON и обеспечения взаимодействия с экземплярами объекта домена с использованием HTTP GET, POST, PUT и DELETE.

Согласно стандарту, URI будут иметь вид:

• api.example.com/object/user/31
• api.example.com/object/user/31/properties/username
• api.example.com/object/user/31/collections/channels
• api.example.com/object/user/31/collections/members
• api.example.com/object/user/31/actions/someFunction
• api.example.com/object/user/31/actions/someFunction/invoke

Есть и другие ресурсы

• api.example.com/services
• api.example.com/domain-types

Спецификация определяет несколько основных представлений:

• объект (который представляет любой объект или службу домена)
• список (ссылок на другие объекты)
• имущество
• коллекция
• действие
• результат действия (обычно содержащий либо объект, либо список, либо просто сообщения обратной связи)
• а также небольшое количество вторичных представлений, таких как домашний и пользовательский

Это интересно, поскольку вы увидите, что репрезентации полностью описывают себя, открывая возможность реализации общих средств просмотра, если это необходимо.

В качестве альтернативы, представления могут быть использованы непосредственно специальным приложением.

Вот мои выводы по результатам многочасового поиска и с учетом отзывов респондентов:

Если у меня есть объект, который фактически представляет собой объект, состоящий из нескольких частей, мне нужно рассматривать его как единый ресурс. Таким образом, если я ПОЛУЧАЮ объект, все подчиненные должны присутствовать. Это необходимо для кэширования ресурса. Если я частично загружаю объект (и предоставляю метку ETag), тогда другие запрашивающие могут получить частичный объект, когда они ожидали получить полный. Завершить - объекты должны быть полностью заполнены, если они доступны в качестве ресурсов.

Связанные объектные отношения должны быть доступны в виде ссылок на другие (первичные) ресурсы. Таким образом, объекты могут быть обнаружены при обходе API.

Кроме того, иерархия объектов, которая имеет смысл для основного сайта приложения, может показаться не тем, что вам нужно для действий в стиле RESTful, но, скорее всего, выявляет проблемы с существующей иерархией. При этом для API могут потребоваться более специализированные варианты использования, чем предполагалось ранее, и могут потребоваться специализированные ресурсы.

Надеюсь, это кому-то поможет