Рекомендации по структуре REST URL

Question

Я пытаюсь завершить работу над структурой URL для списка пожеланий на сайте, над которым я работаю.Это довольно простая модель, у пользователя может быть много списков желаний, и каждый список желаний может содержать много товаров.

В настоящее время у меня есть очевидные CRUD-URL для управления самим списком желаний:

GET account/wishlists.json
GET account/wishlists/{id}.json
POST account/wishlists.json?name=My%20Wishlist
POST account/wishlists/{id}.json?name=My%20New%20Name
DELETE account/wishlists/{id}.json

Однако,Я не думаю, что знаю, как структурировать URL, которые бы добавляли / удаляли продукт в список желаний: (* ​​1006 *

Вот мои текущие варианты:

1) Предложите добавить продукт как часть URL-адреса и используйте HTTP-глагол, чтобы определить мое действие

POST account/wishlist/{id}/product/{product_id}.json
DELETE account/wishlist/{id}/product/{product_id}.json

или

2 ) Выполните действие как частьURL и идентификатор продукта как часть полезной нагрузки

POST account/wishlist/{id}/add.json?product_id={product_id}
POST account/wishlist/{id}/remove.json?product_id={product_id}

(1) являются чистыми и, насколько я могу судить, довольно RESTful, но не позволяют легко добавлять несколько продуктов и т. Д.

Я также немного обеспокоен использованием глагола DELETE - я не удаляю продукт или список желаний, я просто удаляю одно из другого.

(2) более явноно отклоняется от REST - я бы не просто ссылался на ресурс вURL, я бы имел в виду операцию на этом ресурсе: (

Любой совет по поводу того, что из вышеперечисленного было бы более правильным, был бы очень полезен!(Если есть третий вариант, который лучше моего, не стесняйтесь меня поправлять!)

Answer 1

(1) является единственным допустимым подходом для REST, использующим глаголы HTTP для действий.

(2) кодирует имена методов в URI, который больше похож на RPC и, конечно, не RESTful.

Относительно ваших недостатков в первом подходе:

• Глагол DELETE в порядке, потому что ваш ресурс - это элемент внутри списка желаний, а не сам элемент.
• Выможет поддерживать пакетные запросы.Например, вы можете захотеть разрешить POST список элементов для ресурса списка желаний, что приводит к добавлению mutliple.

PS: предпочтение согласования содержимого HTTP (заголовки Accept и Content-Type) над представлениемформаты, закодированные в URI.

Answer 2

Я думаю, что ваш первый вариант больше соответствует философии REST. Если вы хотите управлять несколькими продуктами, вы можете передать идентификаторы в виде списка в теле вместо использования параметра запроса.

Что касается части удаления, учитывая, что вы удаляете подресурс списка пожеланий, я думаю, что намерение ясно (то есть удалите соединение из списка пожеланий с продуктом). Если вы хотите глобально удалить продукт, URL-адрес должен быть примерно таким:

DELETE /products/{id}

Answer 3

Вот хорошая статья о том, как думать о REST URL

Answer 4

Как отмечается в других ответах, первый вариант - это подход RESTful. Подход к удалению продуктов из списка пожеланий выглядит хорошо - в конце концов, вам нужно будет DELETE на product/{product_id} удалить сам продукт.

Для добавления продуктов вы можете рассмотреть варианты от POST до account/wishlist/{id}/product/, текст которых может содержать список идентификаторов продуктов.