В вычислениях метод PATCH — это метод запроса HTTP для внесения частичных изменений в существующий ресурс. [1] Метод PATCH предоставляет объект, содержащий список изменений, которые должны быть применены к запрошенному ресурсу с использованием универсального идентификатора ресурса HTTP (URI). [1] Список изменений предоставляется в виде PATCH-документа. [1] Если запрошенный ресурс не существует, сервер может создать ресурс в зависимости от типа носителя документа PATCH и разрешений. [1] Изменения, описанные в документе PATCH, должны быть семантически четко определены, но могут иметь другой тип носителя , чем исправляемый ресурс. [2] Для описания изменений в документе PATCH можно использовать такие языки, как XML или JSON .
Согласно семантике, определенной в протоколе HTTP , методы GET , PUT и POST должны использовать полное представление ресурса. Метод PUT, который можно использовать для создания или замены ресурсов, является идемпотентным и может использоваться только для полных обновлений. Формы редактирования, используемые в обычных приложениях Ruby on Rails, должны создавать новые ресурсы путем применения частичных обновлений к родительскому ресурсу. В связи с этим требованием в 2010 году в протокол HTTP был добавлен метод PATCH. [3] [4]
HTTP является основой передачи данных во Всемирной паутине . Это протокол запроса-ответа , который помогает пользователям взаимодействовать с сервером для выполнения операций CRUD . HTTP определяет ряд методов запроса, таких как PUT , POST и PATCH, для создания или обновления ресурсов. [5]
Основное различие между методами PUT и PATCH заключается в том, что метод PUT использует URI запроса для предоставления измененной версии запрошенного ресурса, которая заменяет исходную версию ресурса, тогда как метод PATCH предоставляет набор инструкций для изменения ресурса. Если документ PATCH превышает размер новой версии ресурса, отправленной методом PUT, то метод PUT является предпочтительным. [1]
Метод POST можно использовать для отправки частичных обновлений ресурса. Основное различие между методами POST и PATCH заключается в том, что метод POST можно использовать только в том случае, если он написан для поддержки приложений или приложения поддерживают его семантику, тогда как метод PATCH можно использовать в общем виде и не требует поддержки приложения. Если результат использования метода PATCH неизвестен, то предпочтительным является метод POST. [1] [6]
Метод PATCH является атомарным . [1] Либо применяются все изменения, указанные методом PATCH, либо ни одно из изменений не применяется сервером. [1] Существует множество способов проверить, успешно ли было применено исправление. Например, утилиту diff можно применить к старой и новой версии файла, чтобы найти различия между ними. [1]
Кэшированный ответ PATCH считается устаревшим. Его можно использовать только для запросов GET и HEAD, которые могут следовать за запросом PATCH. [1]
Заголовки объектов в документе PATCH применимы только к документу PATCH и не могут быть применены к запрошенному ресурсу. [1]
Для документа PATCH не существует стандартного формата, и он различен для разных типов ресурсов. Сервер должен проверить, соответствует ли полученный документ PATCH запрошенному ресурсу. [1]
Документ JSON Patch будет выглядеть так
[ { "op" : "add" , "path" : "/count" , "value" : 1 } ] «op» представляет операцию, выполняемую с ресурсом. «путь» представляет изменяемый ресурс. «значение» представляет собой сумму, добавляемую к существующему ресурсу. [7] Прежде чем применить изменения в документе PATCH, сервер должен проверить, соответствует ли полученный документ PATCH запрошенному ресурсу. Если запрос PATCH успешен, он возвращает ответ 204 . [8]
Документ XML PATCH будет выглядеть так
<add sel= "doc/user[@email='[email protected]']" type= "@address" >
ABC Road </add> Элемент <user> находится с помощью атрибута email. К элементу <user> добавляется новый атрибут «адрес» со значением «ABC Road». [9]
Простой пример запроса PATCH
PATCH /example.txt HTTP/1.1 Хост: www.example.com Тип контента: приложение/пример Если-Match: "c0b42b66e" Длина контента: 120 [ Изменения : документ патча, содержащий все изменения, которые необходимо внести в ресурс example.txt]Успешный ответ PATCH на существующий текстовый файл:
HTTP/1.1 204 No Content Местоположение содержимого: /example.txt ETag : "c0b42b66f"Ответ 204 означает, что запрос успешно обработан. [10]
Использование метода PUT требует большей пропускной способности по сравнению с методом PATCH, когда к ресурсу необходимо применить лишь несколько изменений. [ нужна цитация ] Но когда используется метод PATCH, он обычно включает в себя получение ресурса с сервера, сравнение исходного и нового файлов, создание и отправку файла различий. На стороне сервера сервер должен прочитать файл различий и внести изменения. Это требует больших накладных расходов по сравнению с методом PUT. [11] С другой стороны, метод PUT требует выполнения GET перед PUT, и трудно гарантировать, что ресурс не будет изменен между запросами GET и PUT.
Метод PATCH не является «безопасным» в смысле RFC 2616: он может изменять ресурсы, не обязательно ограничиваясь теми, которые упомянуты в URI . [1]
Метод PATCH не является идемпотентным . Его можно сделать идемпотентным , используя условный запрос. [1] Когда клиент делает условный запрос к ресурсу, запрос успешен только в том случае, если ресурс не обновлялся с момента последнего доступа клиента к этому ресурсу. Это также помогает предотвратить повреждение ресурса, поскольку некоторые обновления ресурса можно выполнять только начиная с определенной базовой точки. [1]
Запрос PATCH может завершиться неудачно, если произойдет любая из следующих ошибок:
Сервер возвращает ответ 400 (неверный запрос), если документ PATCH не отформатирован должным образом. [1]
Сервер возвращает ответ 415 (Неподдерживаемый тип носителя ) с заголовком ответа Accept-Patch, содержащим поддерживаемые типы носителей , когда клиент отправляет документ исправления в формате, не реализованном сервером. Это информирует клиента о том, что отправленный клиентом документ PATCH не может быть применен к запрошенному ресурсу. [1]
Сервер возвращает ответ 422 (необрабатываемый объект), когда сервер понимает документ PATCH, но не может изменить запрошенный ресурс либо потому, что это приводит к тому, что ресурс становится недействительным, либо к какому-либо другому состоянию ошибки. [1]
Сервер возвращает ответ 404 (не найден), когда документ PATCH невозможно применить к несуществующему ресурсу. [1]
Сервер возвращает ответ 409 (конфликт), когда сервер не может применить исправление для текущего состояния ресурса. [1]
Сервер возвращает ответ 412 (предварительное условие не выполнено), если предварительное условие, предоставленное клиентом с использованием заголовка If-Match или If-Unmodified-Since, не выполняется. Если предварительное условие не указано и имеется конфликтующая модификация, сервер возвращает ответ 409 (конфликт). [1]
Сервер возвращает ответ 409 (конфликт), если запросы PATCH к определенному ресурсу необходимо применять в определенном порядке, и сервер не может обрабатывать одновременные запросы PATCH. [1]
Запрос PATCH должен использовать такие механизмы, как условные запросы с использованием Etags и заголовка запроса If-Match, чтобы гарантировать, что данные не будут повреждены во время исправления. [1] В случае сбоя запроса PATCH, сбоя канала или тайм-аута клиент может использовать запрос GET для проверки состояния ресурса. [1] Сервер должен гарантировать, что злонамеренные клиенты не используют метод PATCH для чрезмерного потребления ресурсов сервера. [1]
{{cite journal}}: Требуется цитировать журнал |journal=( помощь )