Как схема URL REST должна быть похожей для древовидной иерархии?

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

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", тогда не предоставьте абсолютно никакие разъяснения или примеры хорошего УСПОКОИТЕЛЬНОГО дизайна.

27
задан Daniel T. 27 January 2010 в 20:54
поделиться

3 ответа

Не создайте API для отдыха на основе структуры URL. Здесь - это то, как я думаю, вы должны пойти на разработку API отдыха.

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

2
ответ дан 28 November 2019 в 05:45
поделиться

Так как продукты могут быть в нескольких магазинах или нескольких полках (категориях?), У меня было бы каждый продукт иметь уникальный номер независимо от его положения в иерархии. Затем используйте плоский номер продукта. Это делает API более стабильной, когда некоторые продукты, например, перемещаются в вашем магазине.

Короче не добавляйте ненужденное избыточность на ваш API. Чтобы получить список SHELVES, идентификатор хранилища достаточно, для списка продуктов ID Shelles достаточно ... и т. Д.

2
ответ дан 28 November 2019 в 05:45
поделиться

Похоже, вы пытаетесь построить много разных случаев использования, но все встроено в один супер обслуживание. Было бы лучше сломать это.

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

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

0
ответ дан 28 November 2019 в 05:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: