Я разрабатываю службу REST и пытаюсь придерживаться соглашений и руководств доктора Роя Филдинга.

Я представляю свой сервис как конечную точку, которая предоставляет набор ресурсов. Ресурс идентифицируется с помощью URI, и клиенты API могут манипулировать ресурсами с помощью семантики HTTP (т. Е. Различные глаголы HTTP отображаются на соответствующие операции через URI).

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

Пример: рассмотрим API, который раскрывает создание и управление продуктами. Учтите также, что товар связан с брендом. При создании имеет смысл выполнить следующее действие: HTTP POST / Brand / {brand_id} / Product [Тело, содержащее данные, необходимые для создания продукта]

Создание возвращает HTTP 201, созданный с заголовком местоположения, который показывает местоположение вновь созданного продукта.

При дальнейших манипуляциях клиенты могли получить доступ к продукту, выполнив: HTTP PUT / Brand / {brand_id} / Product / {product_id} HTTP DELETE / Brand / {brand_id} / Product / {product_id} и т. Д.

Тем не менее, поскольку идентификатор продукта является универсальным в области действия продукта, следующие манипуляции могут выполняться следующим образом: / Product / {product_id} Я сохраняю префикс / Brand / {brand_id} только по соображениям согласованности. На самом деле, идентификатор бренда игнорируется сервисом. Считаете ли вы, что это хорошая практика, и она целесообразна для поддержания четкого, однозначного определения ServiceInterface? Каковы преимущества этого, и так ли это вообще?

Также будут приветствоваться любые указатели на лучшие практики определения URI.

заранее спасибо