Если мы создадим множественный ресурс запроса на обновление, используя метод POST в REST. Как это повлияет на стороне сервера, если будет создан номер ресурса.
Прежде всего, HTTP, де-факто транспортный уровень REST, - это прикладной протокол для передачи документов по сети , а не только ВАШ домен приложения, в котором вы можете выполнять свои бизнес-правила. Любые бизнес-правила, которые вы выводите из отправки данных по сети, являются лишь побочным эффектом фактического управления документацией, которое вы выполняете через HTTP. В то время как некоторые вещи могут хорошо отображаться из управления документацией на бизнес-уровне, некоторые вещи могут не сработать. То есть HTTP не предназначен для поддержки больших видов пакетной обработки.
Таким образом, даже если HTTP сам определяет набор методов , которые вы можете использовать, с IANA, администрирующими дополнительные , фактическая реализация зависит от самого сервера. Он должен следовать семантике в RFC, хотя может и не соответствовать. Это может повредить совместимости с другими клиентами, хотя в таком случае, поэтому рекомендуется следовать спецификации.
То, какое влияние или влияние может оказать запрос на сервер, зависит от нескольких факторов, таких как тип сервера, данные, которые необходимо обработать, и возможность загрузки работы, т. Е. С помощью кэша, а также внутренняя инфраструктура, которую вы используете. Если у вас есть сервер, который поддерживает пару сотен ядер и терабайт адресного пространства, то обрабатываемый запрос может оказать меньшее влияние на сервер, чем если бы у вас был сервер с одним ядром ЦП и всего лишь гигабайтом ОЗУ, который должен вписаться в пару других приложений, а также самой ОС. В целом, хотя фактическое влияние, которое запрос оказывает на сервер, не зависит от выполняемой вами операции, поскольку по своей сути HTTP - это просто протокол удаленного управления документами, как объяснялось ранее. Некоторые методы, такие как PATCH, могут быть исключением из этого правила, хотя оно явно требует поддержки транзакций, поскольку необходимо применять все или ни одну из операций, определенных в документе исправления.
Я знаю, что используя запрос put, мы можем добиться отказоустойчивости благодаря idempotence.Если мы используем post вместо put, что произойдет?
RFC 7231 включает подсказку о разнице между POST и PUT:
Принципиальное различие между методами POST и PUT подчеркивается различным намерением для вложенного представления. Целевой ресурс в запросе POST предназначен для обработки вложенного представления в соответствии с собственной семантикой ресурса, тогда как вложенное представление в запросе PUT определяется как замена состояния целевого ресурса. Следовательно, намерение PUT является идемпотентным и видимым для посредников, хотя точный эффект известен только серверу происхождения.
POST не дает клиенту никаких обещаний о том, что происходит в случае сетевой ошибки, т. Е. Вы можете не знать, достиг ли запрос сервер, и только ответ был потерян, или фактический запрос не поступил сервер вообще. Джим Уэббер привел пример, почему идемпотентность важна, особенно когда вы имеете дело с деньгами и валютой.
HTTP довольно специфичен для информирования клиента о создании ресурса путем включения заголовка HTTP Location в ответ, который содержит URI для созданного ресурса. Это работает на POST, а также PUT и PATCH. Эта предпосылка теперь может быть использована для «безопасной» загрузки данных. Клиент может отправлять POST запросы на сервер, пока не получит ответ с заголовком Location, указывающим на созданный ресурс, который затем используется на следующем шаге для выполнения PUT обновления этого ресурса с фактическим содержимым. Этот шаблон называется шаблоном создания POST-PUT, и он особенно полезен, если вы хотите отправить большую полезную нагрузку или должны гарантировать, что состояние запускает бизнес-правило только один раз, то есть в случае онлайн покупки.
Обратите внимание, что с помощью условных запросов может также использоваться некоторая форма оптимистической блокировки, хотя для этого потребуется, по крайней мере, заранее узнать состояние текущего ресурса, как здесь определенное значение, что является уникальным для текущего состояния, включается в запрос, который действует как распределенная блокировка, которая, если она отличается от состояния, в котором находится сервер в данный момент, поскольку в то же время могло произойти обновление другим клиентом, приведет к отклонению запрос на стороне сервера.
Если мы создали номер ресурса, используя сообщение для обновления, есть ли проблема с производительностью? Если мы создали номер ресурса, то как это повлияет на сервер?
Я не совсем уверен, что вы подразумеваете под created a number of resources using post for update. Хотите создать или обновить ресурс через POST? Эти методы просто отличаются семантикой, которую они обещают. Как вы отображаете событие модификации документа, чтобы вызвать определенные бизнес-правила в вашем бэкэнде, полностью зависит от вас. В целом, как уже упоминалось, HTTP не идеален с точки зрения пакетной обработки.
В post и put, если мы вызываем один и тот же запрос n раз, мы собираемся подключиться к серверу n раз, тогда создание нового ресурса и того же ресурса не должно влиять на сервер. Пожалуйста, подтвердите это утверждение правильно или неверно
Если вы отправите n запросов через POST на сервер, сервер будет выполнять логику, которая должна выполняться для POST запросов n раз (если все запросы достигли сервера). Будет ли создан новый ресурс или нет, зависит от реализации. Запрос POST может только запустить процесс поддержки, какой-то расчет или фактически ничего не делать. Если он был создан, ответ должен содержать заголовок Location с URI, который указывает на местоположение нового ресурса.
С точки зрения отправки n запросов через PUT, если один и тот же URI используется для всех этих запросов, сервер в целом должен применить полезную нагрузку в качестве нового состояния целевого ресурса. Если это внутренне приводит к обновлению БД или нет, это деталь реализации, которая может сильно отличаться от проекта к проекту. В общем случае запрос PUT не отражается при создании нового ресурса, если только ресурс, на который указывал целевой URI, ранее не существовал, хотя он также может создавать дополнительные ресурсы в качестве побочного эффекта. Представьте себе, если вы разрабатываете какую-то систему контроля версий. PUT разрешено иметь побочные эффекты. Такой побочный эффект может заключаться в том, что вы выполняете обновление магистрали HEAD, которое применяет новое состояние к HEAD, хотя в качестве побочного эффекта для этой фиксации в истории фиксации создается новый ресурс.
Таким образом, в общем, вы не можете оценить влияние запроса на сервер исключительно на основе используемой вами операции HTTP, поскольку в своей основе HTTP - это просто протокол приложения, который передает документы по сети. Фактические бизнес-правила, которые запускаются, являются лишь побочным эффектом фактического управления документами. Какое влияние запрос оказывает на сервер, зависит от множества факторов, таких как тип используемого вами сервера, а также от длины запроса и от того, что вы делаете с ним на сервере. Каждый из доступных методов имеет свою семантику, и вы должны сравнивать их не по тому воздействию, которое они могут оказать на сервер, а по предположению, которое они дают клиенту. Некоторые вещи, такие как что-либо, связанное с балансом или деньгами, должны выполняться через PUT из-за идемпотентного свойства этого метода.