Блог

1. Если мы создадим несколько ресурсов запроса на обновление, используя метод POST в REST.каково будет влияние на стороне сервера, если количество созданных ресурсов.
2. Я знаю, что с помощью запроса put мы можем достичь отказоустойчивости из-за идемпотентности.если мы используем post вместо put, что произойдет?
3. Если мы создали количество ресурсов, используя post для обновления, есть ли какие-либо проблемы с производительностью?если мы создали количество ресурсов, то каково влияние на сервер?
4. В post и put, если мы вызываем один и тот же запрос n раз, мы собираемся обращаться к серверу n раз, а затем создавать новый ресурс, и тот же ресурс не должен влиять на сервер. пожалуйста, подтвердите это утверждение правильно или неправильно.

Если мы создадим несколько ресурсов запроса на обновление, используя метод POST в REST.каково будет влияние на стороне сервера, если количество созданных ресурсов.

Прежде всего, HTTP, фактический транспортный уровень REST, представляет собой протокол приложения для передачи документов по сети, а не только домен ВАШЕГО приложения, на котором вы можете запускать свои бизнес-правила. Любые бизнес-правила, которые вы выводите из отправки данных по сети, являются лишь побочным эффектом фактического управления документацией, которое вы выполняете через HTTP. Хотя некоторые тонкости могут хорошо соотноситься с управлением документацией на вашем бизнес-уровне, некоторые вещи могут и не совпадать. Т.е. HTTP не предназначен для поддержки более крупных видов пакетной обработки.

Таким образом, несмотря на то, что сам HTTP определяет набор методов, которые вы можете использовать, а IANA администрирует дополнительные, фактическая реализация зависит от самого сервера. Это должно соответствовать описанию семантики в RFC, хотя может и не соответствовать. Хотя в таком случае это может повредить взаимодействию с другими клиентами, именно поэтому рекомендуется следовать спецификации.

Какие последствия или влияние запрос может оказать на сервер, зависит от нескольких факторов, таких как тип сервера, данные, которые необходимо обработать, и можно ли разгрузить работу, например, с помощью кэша, а также от используемой вами внутренней инфраструктуры. Если у вас есть сервер, который поддерживает пару сотен ядер и терабайт адресного пространства, обрабатываемый запрос может оказать меньшее влияние на сервер, чем если бы у вас был сервер с одним ядром процессора и всего лишь гигабайтом оперативной памяти, который должен соответствовать нескольким другим приложенияма также на саму ОС. В целом, хотя фактическое влияние, которое запрос оказывает на сервер, не зависит от вызываемой вами операции, поскольку по своей сути HTTP — это просто протокол удаленного управления документами, как объяснялось ранее. Некоторые методы, такие как ИСПРАВЛЕНИЕ, могут быть исключением из этого правила, поскольку оно явно требует поддержки транзакций, поскольку необходимо применять либо все, либо ни одну из операций, определенных в документе исправления.

Я знаю, что с помощью запроса put мы можем достичь отказоустойчивости из-за идемпотентности.если мы используем post вместо put, что произойдет?

RFC 7231 содержит подсказку о разнице между POST и PUT :

Фундаментальное различие между методами POST и PUT подчеркивается различным намерением для вложенного представления. Целевой ресурс в запросе POST предназначен для обработки вложенного представления в соответствии с собственной семантикой ресурса, тогда как вложенное представление в запросе PUT определяется как замена состояния целевого ресурса. Следовательно, цель PUT является идемпотентной и видимой для посредников, хотя точный эффект известен только исходному серверу.

POST не дает клиенту никаких обещаний относительно того, что произойдет в случае сетевой ошибки, т.Е. Вы можете не знать, достиг ли запрос сервера, и только ответ был потерян, или если фактический запрос вообще не попал на сервер. Джим Уэббер привел пример, почему важна идемпотентность, особенно когда вы имеете дело с деньгами и валютами.

HTTP довольно специфичен для информирования клиента о создании ресурса путем включения Location заголовка HTTP в ответ, который содержит URI для созданного ресурса. Это работает POST так же хорошо, как PUT и PATCH . Теперь эту предпосылку можно использовать для «безопасной» загрузки данных. Клиент может отправлять POST запросы на сервер до тех пор, пока не получит ответ с Location заголовком, указывающим на созданный ресурс, который затем используется на следующем шаге для выполнения PUT обновления этого ресурса с фактическим содержимым. Этот шаблон называется шаблоном POST-PUT создания, и он особенно полезен, если у вас либо большая полезная нагрузка для отправки, либо вам нужно гарантировать, что состояние запускает бизнес-правило только один раз, т. Е. В случае онлайн-покупки.

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

Если мы создали количество ресурсов, используя post для обновления, есть ли какие-либо проблемы с производительностью?если мы создали количество ресурсов, то каково влияние на сервер?

Я не совсем уверен, что вы имеете в виду 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 из-за идемпотентного свойства этого метода.