Qual é a principal diferença entre a solicitação PATCH e PUT?


187

Estou usando uma PUTsolicitação no meu aplicativo Rails. Agora, um novo verbo HTTP PATCHfoi implementado pelos navegadores. Então, quero saber qual é a principal diferença entre PATCHe PUTsolicitações e quando devemos usar uma ou outra.

Respostas:


139

Os verbos HTTP são provavelmente uma das coisas mais enigmáticas do protocolo HTTP. Eles existem, e existem muitos deles, mas por que existem?

O Rails parece querer suportar muitos verbos e adicionar alguns verbos que não são suportados pelos navegadores da web nativamente.

Aqui está uma lista exaustiva de verbos http: http://annevankesteren.nl/2007/10/http-methods

Existe o patch HTTP do RFC oficial: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

O método PATCH solicita que um conjunto de alterações descrito na entidade solicitante seja aplicado ao recurso identificado pelo Request-URI. O conjunto de alterações é representado em um formato chamado "documento de correção" identificado por um tipo de mídia. Se o Request-URI não apontar para um recurso existente, o servidor PODE criar um novo recurso, dependendo do tipo de documento do patch (se ele pode modificar logicamente um recurso nulo) e permissões, etc.

A diferença entre as solicitações PUT e PATCH é refletida na maneira como o servidor processa a entidade fechada para modificar o recurso identificado pelo Request-URI. Em uma solicitação PUT , a entidade fechada é considerada uma versão modificada do recurso armazenado no servidor de origem e o cliente está solicitando a substituição da versão armazenada. Com PATCH , no entanto, a entidade incluída contém um conjunto de instruções que descrevem como um recurso que atualmente reside no servidor de origem deve ser modificado para produzir uma nova versão. O método PATCH afeta o recurso identificado pelo Request-URI , e também PODEter efeitos colaterais em outros recursos; ou seja, novos recursos podem ser criados, ou os existentes modificados, pela aplicação de um PATCH .

Até onde eu sei, o verbo PATCH não é usado como em aplicativos de trilhos ... Pelo que entendi, o verbo RFC do patch deve ser usado para enviar instruções de patch, como quando você faz uma diferença entre dois arquivos. Em vez de enviar a entidade inteira novamente, você envia um patch que pode ser muito menor do que reenviar a entidade inteira.

Imagine que você deseja editar um arquivo enorme. Você edita 3 linhas. Em vez de enviar o arquivo de volta, basta enviar o diff. No lado positivo, o envio de uma solicitação de patch pode ser usado para mesclar arquivos de forma assíncrona. Um sistema de controle de versão poderia usar o verbo PATCH para atualizar o código remotamente.

Um outro caso de uso possível está relacionado aos bancos de dados NoSQL, é possível armazenar documentos. Digamos que usamos uma estrutura JSON para enviar e receber dados do servidor para o cliente. Se quiséssemos excluir um campo, poderíamos usar uma sintaxe semelhante à do mongodb para $ unset . Na verdade, o método usado no mongodb para atualizar documentos provavelmente poderia ser usado para manipular patches json.

Tomando este exemplo:

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

Poderíamos ter algo assim:

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

Por último, mas não menos importante, as pessoas podem dizer o que quiserem sobre os verbos HTTP. Existe apenas uma verdade, e a verdade está nos RFCs.


1
É importante observar que a RFC 5789 ainda está em fase de proposta e não foi oficialmente aceita e atualmente é sinalizada como 'irrata existe'. Essa 'melhor prática' é altamente debatida e tecnicamente o PATCH ainda não faz parte do padrão HTTP. A única verdade aqui é que, como o RFC é inaceitável, você não deve fazê-lo.
usar o seguinte código

3
Mesmo se ainda estiver em proposta, isso não significa que não deva ser usado. Se fosse o caso, não poderíamos usar websockets e muitos outros rfcs que ainda estão em proposta ... A implementação da proposta é 100 vezes melhor do que a implementação de algo completamente personalizado que ninguém mais implementa.
Loïc Faure-Lacroix

BS. Ele não está "em proposta" e faz parte do padrão HTTP (o padrão, o RFC 7231 delega a um registro da IANA para métodos, e o PATCH está listado lá).
Julian Reschke

@ JulianReschke, se você ler a segunda linha desta RFC, verá que ela ainda está marcada como PADRÃO PROPOSTA . Portanto, não, o método do patch ainda está em proposta. O rfc está aqui entre. tools.ietf.org/html/rfc5789 e o rfc7231 também são PROPOSTA PADRÃO . Se você olhar para o RFC821, por exemplo, está marcado como INTERNET STANDARD
Loïc Faure-Lacroix

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... Não é a minha palavra. Um padrão proposto não significa que você não possa implementá-lo corretamente, como expliquei acima. Isso não significa que não seja estável o suficiente para implementar ... mas ainda está em proposta, a menos que esteja marcado como Padrão da Internet ... Não tenho certeza de como você está discutindo isso. É chamado de "padrão proposto" e não pode significar nada além de uma proposta. Se você quiser argumentar que um padrão proposto pode ser usado. É exatamente o que eu escrevi.
precisa

104

Passei algumas horas com o google e encontrei a resposta aqui

PUT => Se o usuário puder atualizar todo ou apenas uma parte do registro , use PUT (o usuário controla o que é atualizado)

PUT /users/123/email
new.email@example.org

PATCH => Se o usuário puder atualizar apenas um registro parcial , diga apenas um endereço de email (o aplicativo controla o que pode ser atualizado), use PATCH.

PATCH /users/123
[description of changes]

Por quê Patch

PUTO método precisa de mais largura de banda ou manipular recursos completos em vez de parcial. Então PATCHfoi introduzido para reduzir a largura de banda.

Explicação sobre PATCH

PATCH é um método que não é seguro nem idempotente e permite atualizações completas e parciais e efeitos colaterais em outros recursos.

PATCH é um método cuja entidade fechada contém um conjunto de instruções que descrevem como um recurso que atualmente reside no servidor de origem deve ser modificado para produzir uma nova versão.

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

Aqui mais informações sobre colocar e corrigir


7
Por que esse PATCH não é seguro?
Bishisht Bhatta

1
PATCHentre POST, PUTetc. não é "seguro", porque modifica seus dados (tem efeitos colaterais). Em comparação com GET, OPTIONSetc. (métodos seguros), onde você pode chamar os pontos de extremidade várias vezes sem efeitos colaterais.
Emix

1
O PATCH NÃO foi introduzido para salvar apenas a largura de banda. Como a RFC 5789 afirma:> "É necessário um novo método para melhorar a interoperabilidade e evitar erros." No ambiente paralelo múltiplo, ter apenas PUTs que incluam o restante da carga útil aumentaria o risco de modificação de outros atributos do recurso. PATCH resolve esse problema.
Tomasz Nazar

43

put
se eu quiser mudar meu firstnome então envie put put for Update

{ "first": "Nazmul", "last": "hasan" } 

mas aqui tem um problema é putsolicitar que, quando eu quiser enviar uma putsolicitação, eu tenho que enviar todos os dois parâmetros que são firste, last
portanto, é obrigatório enviar todo o valor novamente

patch :
patchpedido diz. envie apenas o dataque você deseja updatee não afetará ou alterará outros dados.
portanto, não há necessidade de enviar todo o valor novamente. só quero atualizar o meu primeiro nome, então eu preciso enviar apenas o firstnome para atualizar.


13

Aqui está a diferença entre os métodos POST, PUT e PATCH de um protocolo HTTP.

POSTAR

Um método HTTP.POST sempre cria um novo recurso no servidor. É uma solicitação não idempotente, ou seja, se o usuário atender às mesmas solicitações duas vezes, criará outro novo recurso se não houver restrição.

O método http post é como uma consulta INSERT no SQL, que sempre cria um novo registro no banco de dados.

Exemplo: use o método POST para salvar novo usuário, pedido etc., onde o servidor back-end decide a identificação do recurso para o novo recurso.

COLOCAR

No método HTTP.PUT, o recurso é identificado pela URL e, se existir, é atualizado, caso contrário, um novo recurso é criado. Quando o recurso de destino existe, ele substitui esse recurso por um novo corpo completo. Esse é o método HTTP.PUT é usado para criar ou atualizar um recurso.

O método http put é como uma consulta MERGE no SQL que insere ou atualiza um registro, dependendo da existência do registro.

A solicitação PUT é idempotente, ou seja, atender às mesmas solicitações duas vezes atualizaria a gravação existente (nenhum novo registro criado). No método PUT, a identificação do recurso é decidida pelo cliente e fornecida no URL da solicitação.

Exemplo: use o método PUT para atualizar o usuário ou pedido existente.

FRAGMENTO

Um método HTTP.PATCH é usado para modificações parciais em um recurso, ou seja, atualizações delta.

O método de patch http é como uma consulta UPDATE no SQL que define ou atualiza apenas as colunas selecionadas e não a linha inteira.

Exemplo: você pode usar o método PATCH para atualizar o status do pedido.

PATCH / api / users / 40450236 / order / 10234557

Corpo da solicitação: {status: 'Delivered'}


Esta é a pior explicação que alguém pode ler sobre put and patch. Além disso, depois de tantas boas respostas postadas, o que faz você pensar que sua resposta é diferente aqui?
CodeHunter 5/09/19

3

Existem limitações em PUT over PATCH ao fazer atualizações. O uso de PUT exige que especifiquemos todos os atributos, mesmo que desejemos alterar apenas um atributo. Mas se usarmos o método PATCH, podemos atualizar apenas os campos de que precisamos e não há necessidade de mencionar todos os campos. PATCH não nos permite modificar um valor em uma matriz ou remover um atributo ou entrada de matriz.


1

Os métodos PUT e PATCH são de natureza semelhante, mas há uma diferença fundamental.

PUT - na solicitação PUT , a entidade fechada seria considerada como a versão modificada de um recurso que reside no servidor e seria substituída por essa entidade modificada.

PATCH - na solicitação PATCH , a entidade fechada contém o conjunto de instruções de como a entidade que residia no servidor seria modificada para produzir uma versão mais recente.


1

De acordo com os termos HTTP, a PUTsolicitação é como uma declaração de atualização do banco de dados. PUT- é usado para modificar o recurso existente (anteriormente publicado). Por outro lado, a PATCHsolicitação é usada para atualizar uma parte do recurso existente.

Por exemplo:

Detalhes do cliente:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";
//..

Quando queremos atualizar para o registro inteiro? nós temos que usar Http PUT verbpara isso.

tal como:

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";
//..

Por outro lado, se quisermos atualizar apenas a parte do registro e não o registro inteiro, prossiga Http PATCH verb. tal como:

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";
   //..

PUT VS POST:

Ao usar PUTrequest, temos que enviar todos os parâmetros, como firstName, lastName, email, phoneNumber Where as In patchrequest envia apenas os parâmetros que queremos atualizar e não afetará ou alterará outros dados.

Para obter mais detalhes, visite: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

O método Put e Patch é semelhante. Mas nos trilhos, ele tem um método diferente. Se queremos atualizar / substituir o registro inteiro, precisamos usar o método Put. Se quisermos atualizar um registro específico, use o método Patch.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.