С REST API существует ли соглашение для клиентов, проверяющих запрос без каких-либо изменений?

Это может быть проще всего объяснить в примере использования.

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

Чтобы улучшить пользовательский интерфейс, было бы неплохо проверить количество введенного пользователем, прежде чем они даже нажмут Add. Это потребовало бы отправки запроса на сервер, который будет проверять, будет ли при нажатии Add возникнуть ошибка, но он не будет вносить никаких изменений в тележка, если нет ошибки.

Один из моих сотрудников предложил добавить параметры запроса ?intent=validate к любым конечным точкам, которым требуется такая функциональность. Это звучит неплохо, потому что мне не нужно создавать дополнительные конечные точки.

Существуют ли какие-либо общие соглашения для API REST для обработки такого запроса «проверять, но не совершать ничего»? Подходит ли подход ?intent=validate к красным флагам?


UPDATE:

Спасибо за отзыв, но я должен, вероятно, прояснить некоторые вещи.

  1. Я действительно не работаю на сайте электронной коммерции, я просто использовал это для простого объяснения. На самом деле я работаю с платформой для управления документами.
  2. Пользователи могут запрашивать массовые действия, например перемещение 100 документов и папок в папку. Есть много вещей, которые необходимо проверить для любого такого запроса, например прав пользователя по документам и папкам, конфликтов имен, не перемещать папку в себя и т. Д. Поэтому я действительно хочу проверять каждый раз, когда пользователь проверяет флажок в список документов для перемещения.
  3. API будет по-прежнему проверять, когда пользователь нажимает Submit, чтобы зафиксировать их изменения, поскольку есть другие пользователи, которые одновременно выполняют действия , Дело в том, чтобы дать пользователям раннюю обратную связь, поэтому они не тратят время на проверку 100 ящиков, чтобы узнать, что им нужно переименовать 2 документа перед совершением.
  4. В этой системе есть много других массовых запросов, которые нужно обрабатывать одинаково, например, изменять права пользователей по объектам, массовые удаления, назначать несколько пользователей группам пользователей и т. д. Поэтому было бы неплохо, если бы каждый тип запрос не требовал отдельной проверки и фиксации конечных точек.
3 голоса | спросил JamesFaix 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 23 Sep 2017 19:24:56 +0300 2017, 19:24:56

4 ответа


3
  

С REST API существует ли соглашение для клиентов, проверяющее запрос без каких-либо изменений?

Не совсем, не так, как вы. REST не волнует, какое правописание вы используете для своих идентификаторов; в REST, URI непрозрачны. Клиент просто следует за предоставленными ссылками.

Итак, вы можете отправить подтверждение данных на /c255ed19-d6b0-4666-b9cc-abc48d4246ae и фактический запрос «сделать это» на fbb43bdf-0016-4aa1-9f55-28b884238d40, а в отношении REST это написание fine .

Таким образом, изменение идентификатора ресурса для включения параметра intent=validate в URI в порядке. Если вместо этого вы решили различать намерение, используя другое правописание в сегментах пути, это также прекрасно. REST не заботится ; любой смысл, закодированный в URI, выполняется по усмотрению сервера и для его исключительного использования.

Конечно, если написание URI непрозрачно, тогда это правописание не передает никакой полезной семантики. Там должен быть дополнительный слой косвенности ; в REST, что-то есть ссылка - тип отношения - это внеполосная информация, которую клиент и сервер соглашаются заранее. В идеальном случае отношение, которое вам нужно, уже стандартизировано; вы можете проверить реестр связей связей , чтобы узнать, вам нужна информация. Если нет, вы можете создать на заказ тип отношения расширения и назначить ему значение.

<link rel="http://example.org/relations/validateOrder" target="/c255ed19-d6b0-4666-b9cc-abc48d4246ae" />
<link rel="http://example.org/relations/placeOrder" target="/fbb43bdf-0016-4aa1-9f55-28b884238d40" />

Вы можете отличать свои собственные идентификаторы для определения этих отношений или вы можете искать совпадения между уже существующими схемами

<link rel="http://schema.org/CheckAction" target="/c255ed19-d6b0-4666-b9cc-abc48d4246ae" />
<link rel="http://schema.org/OrderAction" target="/fbb43bdf-0016-4aa1-9f55-28b884238d40" />
ответил VoiceOfUnreason 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 24 Sep 2017 17:50:03 +0300 2017, 17:50:03
1

Проблема с сообщением о подтверждении заключается в том, что он будет немедленно устаревшим.

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

Если вам нужно его реализовать, у меня будет отдельное сообщение «уровень запаса запроса».

ответил Ewan 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 23 Sep 2017 22:21:03 +0300 2017, 22:21:03
1

Для запросов GET вы можете использовать HEAD-глагол, поскольку это более или менее то, для чего он предназначен (например, должен предоставить вам код состояния сервера). Для POST вы МОЖЕТЕ попытаться свернуть ВАРИАНТЫ.

Однако, я считаю, что в основном это семантика. Поскольку для конкретного варианта использования вам действительно нужны два разных API: /validate и /order, причем оба запроса POST. Это выражает намерение самым ясным образом.

ответил zaitsman 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 24 Sep 2017 02:32:17 +0300 2017, 02:32:17
-2

Ответ на проблему с управлением документами.

Вы должны проверить на стороне клиента логику js, отправить запрос, проверить серверную сторону, вызвать ошибку проверки, если есть проблема.

Вы можете пропустить проверку на стороне клиента, но это делает сообщение возврата с сервера сложным, так как вам понадобится список отказов проверки.

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

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

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

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

ответил Ewan 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 24 Sep 2017 11:47:19 +0300 2017, 11:47:19

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132