RESTful POSTS, вы делаете POST объекты единственному или множественному Uri?

Ответ 1

Так как POST - это операция "добавить", она может быть более английской для POST до /products, так как вы добавляете новый продукт в существующий список продуктов.

Пока вы стандартизировали что-то в своем API, я думаю, что это достаточно хорошо.

Так как API REST должен быть основан на гипертексте, URI в любом случае является относительно несущественным. Клиенты должны извлекать URI из возвращенных документов и использовать их в последующих запросах; обычно приложениям и людям не нужно угадывать или визуально интерпретировать URI, так как приложение будет явно указывать клиентам, какие ресурсы и URI доступны.

Ответ 2

Обычно вы используете POST для создания ресурса, когда вы заранее не знаете идентификатор ресурса, и PUT, когда вы это делаете. Таким образом, вы отправили POST в /products или PUT в /products/ {new-id}.

С обоими из них вы вернетесь в 201 Созданный, и с POST дополнительно верните заголовок местоположения, содержащий URL-адрес вновь созданного ресурса (при условии, что он был успешно создан).

Ответ 3

ВЫ ПОСТ или ПОЛУЧИТЕ одну вещь: один ПРОДУКТ.

Иногда вы получаете GET без определенного продукта (или с критериями запроса). Но вы все еще говорите это в единственном числе.

Вы редко работаете с множественными формами имен. Если у вас есть коллекция (Каталог продуктов), это один каталог.

Ответ 4

В дизайне RESTful существует несколько шаблонов для создания новых ресурсов. Выбранный вами шаблон в значительной степени зависит от того, кто несет ответственность за выбор URL-адреса для вновь созданного ресурса.

Если клиент отвечает за выбор URL-адреса, клиент должен указать URL-адрес ресурса. В отличие от этого, если сервер отвечает за URL-адрес ресурса, клиент должен использовать POST для ресурса "factory". Как правило, ресурс factory является родительским ресурсом создаваемого ресурса и обычно представляет собой набор, который является плюрализованным.

Итак, в вашем случае я бы рекомендовал использовать /products

Ответ 5

Я бы опубликовал только сингулярный /product. Слишком просто смешивать два URL-адреса и путаться или ошибаться.

Ответ 6

Как многие говорили, вы, вероятно, можете выбрать любой стиль, который вам нравится, пока вы согласны, однако я хотел бы указать на некоторые аргументы с обеих сторон; Я лично склонен к сингулярному

В пользу множественных имен ресурсов:

• простота схемы URL, так как вы знаете имя ресурса всегда на множественном числе
• многие считают это соглашение похожим на то, как обращаются с таблицами баз данных и считают это преимуществом
• представляется более широко принятым

В пользу уникальных имен ресурсов (это не исключает множественные числа при работе с несколькими ресурсами)

• Схема URL более сложна, но вы получаете большую выразительность.
• вы всегда знаете, когда имеете дело с одним или несколькими ресурсами, основанными на имени ресурса, в отличие от проверки того, имеет ли ресурс идентификатор пути поиска, следующий за
• множественное число иногда сложнее для носителей без носителей (когда это не просто "s" ).
• URL длиннее
• "s" кажется избыточным с точки зрения программистов.
• просто неудобно рассматривать параметр пути как под-ресурс коллекции, а не считать его тем, чем он является: просто идентификатор ресурса, который он идентифицирует

Ответ 7

вы можете использовать один и тот же URL-адрес для всех из них и использовать MessageContext для определения того, какой тип действий вызывал вызывающий веб-сервис. Язык не указан, но в Java вы можете сделать что-то вроде этого.

WebServiceContext ws_ctx;
MessageContext ctx = ws_ctx.getMessageContext();
String action = (String)ctx.get(MessageContext.HTTP_REQUEST_METHOD);
if(action.equals("GET")
  // do something
else if(action.equals("POST")
  // do something

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