Давайте предположим, что у меня есть хранилища, полки в хранилище и продукты на полке. Таким образом, для получения списка продуктов на полке в хранилище, я использовал бы следующий запрос:
GET http://server/stores/123/shelves/456/products
Отсюда, как я получил бы отдельный продукт? Если я использую:
GET http://server/products/789
Или:
GET http://server/stores/123/shelves/456/products/789
Первый метод более краток, с тех пор, как только Вы получаете список продуктов, Вы действительно не заботитесь, какое хранилище он принадлежит тому, если Вы просто хотите посмотреть детали для конкретного продукта. Однако второй метод более логичен, так как Вы просматриваете продукты для определенной полки в определенном хранилище.
Аналогично, что относительно ПОМЕЩАТЬ/УДАЛЯТЬ операции?
DELETE http://server/stores/123/shelves/456/products/789
Или:
DELETE http://server/products/789
Каков был бы корректный способ разработать схему для древовидной иерархии как это?
P.S., Если я неправильно понимаю что-то об остальных архитектура, обеспечьте примеры того, как я могу сделать это лучше. Существуют слишком многие люди, которые любят говорить, что "REST не является CRUD", и "REST не является RPC", тогда не предоставьте абсолютно никакие разъяснения или примеры хорошего УСПОКОИТЕЛЬНОГО дизайна.
Не создайте API для отдыха на основе структуры URL. Здесь - это то, как я думаю, вы должны пойти на разработку API отдыха.
Попытка определить интерфейс отдыха без обсуждения того, какие ссылки будут содержаны в каких ресурсах, как обсуждение интерфейса RPC и игнорирующих параметров и возвратных значений.
Так как продукты могут быть в нескольких магазинах или нескольких полках (категориях?), У меня было бы каждый продукт иметь уникальный номер независимо от его положения в иерархии. Затем используйте плоский номер продукта. Это делает API более стабильной, когда некоторые продукты, например, перемещаются в вашем магазине.
Короче не добавляйте ненужденное избыточность на ваш API. Чтобы получить список SHELVES, идентификатор хранилища достаточно, для списка продуктов ID Shelles достаточно ... и т. Д.
Похоже, вы пытаетесь построить много разных случаев использования, но все встроено в один супер обслуживание. Было бы лучше сломать это.
http://server/product_info/123123 or http://server/product_info?product=123123
http://server/product_inventory?store=123&shelf=345
Тогда вы также можете поддерживать:
http://server/product_inventory?store=123
затем поставить и удалить иметь смысл для изменения инвентаризации или добавления нового продукта.