Разумно ли, чтобы ресурсы REST были единственными и множественными?

Мне было интересно, а не более традиционный макет, как это:

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

Было бы более полезно иметь единственное и множественное число, например:

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

Итак, для создания коллекции продуктов вы можете сделать:

POST api/Products {data: filters} // returns api/Products/<id>

И затем, чтобы сослаться на это, вы можете сделать:

GET api/Products/<id> // returns array of products

На мой взгляд, главное преимущество таких действий состоит в том, что они позволяют легко кэшировать коллекции продуктов. Можно, например, установить целую коллекцию продуктов на один час, что значительно сократит количество обращений к серверу. Конечно, в настоящее время я вижу только хорошую сторону в том, чтобы делать что-то подобное, в чем недостаток?

rest

— Ева
источник

Ответы:

Часто, когда коллекция будет наиболее полезным способом взаимодействия с вашим API, проще будет думать о единственном как о коллекции только с одним членом. Затем, если позже вы захотите выставить API для взаимодействия с одиночными, ему просто нужно будет конвертировать сингл, переданный в коллекцию с этим членом, и затем использовать идентичную реализацию другого API.

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

— Джимми Хоффа
источник

Хотя я согласен с вашим мнением, если предположить, что мы используем приведенный выше пример, учитывая, что api / Products POST будет использоваться для передачи параметров фильтра сбора, а не данных для создания новых продуктов, что было бы разумным способом создания нового продукта. без API / продукта?

— Ева

@Evan Почему нельзя публиковать в api / Продукты вставляют несколько (или коллекцию из одного) продуктов? Это кажется наиболее логичным для меня. Возможно, опубликуйте Продукты / Фильтры для создания фильтров или получите, если это поисковая, а не творческая задача.

— Джимми Хоффа

Спасибо за разработку, Джимми. Причина, по которой я этого не видел, заключалась в том, что в приведенном выше примере я рассматривал коллекцию как идентифицированный ресурс сам по себе. На бэкэнде api / Product может быть «Product», а api / Products - «ProductCollection». Тем не менее, после некоторого рассмотрения, я думаю, что может быть лучше абстрагироваться от API, как в вашем предложении ... теперь к реальному вопросу, уехали ли вы с этого грузовика по дороге в Таиланд или уехали? в багажнике машины?

— Ева

@ Иван, я дам тебе два совета: чайки.

— Джимми Хоффа

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

Если вы хотите смягчить это, вы можете сами создать SDK для вашей службы REST. Или вы можете просто быть самоуверенным и иметь дело с жалобами :)

— Крис Макколл
источник