Я столкнулся с проблемой на работе, где я не могу найти информацию о стандартном стандарте или практике для выполнения операций CRUD в веб-службе RESTful против ресурса, чей первичный ключ является составной частью других идентификаторов ресурсов. Мы используем MVC WebApi для создания контроллеров. Например, у нас есть три таблицы:
-
Product
: PK = ProductId -
Part
: PK = PartId -
ProductPartAssoc
: PK = (ProductId, PartId)
Продукт может иметь много частей, а часть может быть компонентом многих продуктов. Таблица ассоциации также содержит дополнительную информацию, относящуюся к самой ассоциации, которая должна быть доступна для редактирования.
У нас есть классы ProductsController
и PartsController
, которые обрабатывают обычные операции GET/PUT/POST/DELETE с использованием шаблонов маршрутов, определенных как: {controller}/{id}/{action}
, так что работают следующие IRI:
- GET, POST
/api/Products
- возвращает все продукты, создает новый продукт - GET, PUT, DELETE
/api/Products/1
- извлекает/обновляет/удаляет продукт 1 - GET, POST
/api/Parts
- возвращает все части, создает новую часть - GET, PUT, DELETE
/api/Parts/2
- извлекает/обновляет/удаляет часть 2 - GET
/api/Products/1/Parts
- получить все детали для продукта 1 - GET
/api/Parts/2/Products
- получить все продукты, для которых часть 2 является компонентом
В случае возникновения проблем возникает вопрос о том, как определить шаблон маршрута для ресурсов ProductPartAssoc. Каким должен быть шаблон маршрута и IRI для получения данных ассоциации? Соблюдая соглашение, я бы ожидал чего-то вроде:
- GET, POST
/api/ProductPartAssoc
- возвращает все ассоциации, создает ассоциацию - GET, PUT, DELETE
/api/ProductPartAssoc/[1,2]
- извлекает/обновляет/удаляет связь между продуктом 1 и частью 2
Мои коллеги находят это эстетически недовольным, хотя и, похоже, считают, что лучше не иметь класс ProductPartAssocController
, а скорее добавить дополнительные методы в ProductsController
для управления данными ассоциации:
- GET, PUT, DELETE
/api/Products/1/Parts/2
- получить данные для связи между продуктом 1 и частью 2, а не данными для части 2 в качестве члена части 1, что обычно было бы основано на других примерах, таких как/Book/5/Chapter/3
, что я видел в другом месте. - POST Не знаю, чего ожидать от IRI. К сожалению, они являются лицами, принимающими решения.
В конце дня, я думаю, что я ищу, это либо проверка, либо направление, на которое я могу указать, и сказать: "Смотрите, это то, что делают другие люди".
Какова типичная практика для работы с ресурсами, идентифицированными составными ключами?