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

Лучшим советом, который я могу дать, является попытка избежать того, чтобы думать о вашем 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

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

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

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

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

Здесь мои выводы из многих часов поиска и ввода от респондентов здесь:

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

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

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

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