PATCH (HTTP)

Vid beräkning är PATCH- metoden en begäranmetod i HTTP för att göra partiella ändringar i en befintlig resurs. PATCH-metoden tillhandahåller en entitet som innehåller en lista över ändringar som ska tillämpas på den begärda resursen med hjälp av HTTP Uniform Resource Identifier (URI). Listan över ändringar tillhandahålls i form av ett PATCH-dokument. Om den begärda resursen inte finns servern skapa resursen beroende på PATCH-dokumentets mediatyp och behörigheter. Ändringarna som beskrivs i PATCH-dokumentet måste vara semantiskt väldefinierade men kan ha en annan mediatyp än resursen som korrigeras. Språk som XML eller JSON kan användas för att beskriva ändringarna i PATCH-dokumentet.

PATCH:s historia

Enligt semantiken som definieras i HTTP- protokollet måste GET , PUT och POST -metoderna använda en fullständig representation av resursen. PUT-metoden som kan användas för att skapa eller ersätta resurser är idempotent och kan endast användas för fullständiga uppdateringar. Redigeringsformulären som används i konventionella Ruby on Rails -applikationer måste skapa nya resurser genom att tillämpa partiella uppdateringar på en överordnad resurs. På grund av detta krav lades PATCH-metoden till i HTTP-protokollet 2010.

PUT vs PATCH vs POST

HTTP är grunden för datakommunikation för World Wide Web . Det är ett begäran-svar- protokoll som hjälper användare att kommunicera med servern för att utföra CRUD -operationer. HTTP definierar ett antal begäransmetoder såsom PUT , POST och PATCH för att skapa eller uppdatera resurser.

Huvudskillnaden mellan PUT- och PATCH-metoden är att PUT-metoden använder begäran URI för att tillhandahålla en modifierad version av den begärda resursen som ersätter den ursprungliga versionen av resursen, medan PATCH-metoden tillhandahåller en uppsättning instruktioner för att modifiera resursen. Om PATCH-dokumentet är större än storleken på den nya versionen av resursen som skickas med PUT -metoden är PUT -metoden att föredra.

POST-metoden kan användas för att skicka partiella uppdateringar till en resurs. Den största skillnaden mellan POST- och PATCH-metoderna är att POST-metoden endast kan användas när den är skriven för att stödja applikationerna eller applikationerna stöder dess semantik, medan PATCH-metoden kan användas på ett generiskt sätt och inte kräver applikationsstöd. Om resultatet av att använda PATCH-metoden inte är känt är POST-metoden att föredra.

Lappar resurser

PATCH-metoden är atomär . Antingen tillämpas alla ändringar som specificeras av PATCH-metoden eller så tillämpas ingen av ändringarna av servern. Det finns många sätt att kontrollera om en patch har applicerats framgångsrikt. Till exempel verktyget "diff" användas på den äldre versionen och den nyare versionen av en fil för att hitta skillnaderna mellan dem.

Ett cachat PATCH-svar anses vara inaktuellt. Den kan endast användas för GET- och HEAD-begäran som kan följa PATCH-begäran.

Entitetshuvudena i PATCH-dokumentet är endast tillämpliga på PATCH-dokumentet och kan inte tillämpas på den begärda resursen.

Det finns inget standardformat för PATCH-dokumentet och det är olika för olika typer av resurser. Servern måste kontrollera om det mottagna PATCH-dokumentet är lämpligt för den begärda resursen.

Ett JSON Patch- dokument skulle se ut

         
 [  {  "op"  :  "add"  ,  "path"  :  "/count"  ,  "value"  :  1  }  ] 

"op" representerar operationen som utförs på resursen. "sökväg" representerar resursen som ändras. "värde" representerar det belopp som läggs till den befintliga resursen. Innan ändringarna i PATCH-dokumentet tillämpas måste servern kontrollera om det mottagna PATCH-dokumentet är lämpligt för den begärda resursen. Om PATCH-begäran lyckas returnerar den ett 204- svar.

Ett XML PATCH-dokument skulle se ut

   <add  sel=  "doc/user[@email='[email protected]']"  type=  "@address"  >  ABC Road  </add> 

Elementet är lokaliserad med attributet 'e-post'. Ett nytt attribut 'adress' med värdet "ABC Road" läggs till element.

Exempel

Ett enkelt exempel på PATCH-begäran

Lyckad PATCH-svar på befintlig textfil:

     HTTP  /  1.1  204  Inget innehåll  Innehåll-Plats: /example.txt  ETag  : "c0b42b66f" 

Svaret 204 betyder att begäran behandlades framgångsrikt.

Avvägningar mellan PUT och PATCH

Att använda PUT- metoden förbrukar mer bandbredd jämfört med PATCH-metoden när endast ett fåtal ändringar behöver tillämpas på en resurs. Men när PATCH-metoden används, innebär det vanligtvis att man hämtar resursen från servern, jämför de ursprungliga och nya filerna, skapar och skickar en diff-fil. På serversidan måste servern läsa diff-filen och göra ändringarna. Detta innebär en hel del omkostnader jämfört med PUT-metoden. Å andra sidan PUT -metoden att en GET ska utföras före PUT och det är svårt att säkerställa att resursen inte modifieras mellan GET- och PUT -begäran.

Varning

PATCH-metoden är inte "säker" i betydelsen RFC 2616: den kan modifiera resurser, inte nödvändigtvis begränsade till de som nämns i URI: n .

PATCH - metoden är inte idempotent . Det kan göras idempotent genom att använda en villkorad begäran. När en klient gör en villkorlig begäran till en resurs, lyckas begäran endast om resursen inte har uppdaterats sedan klienten senast fick åtkomst till den resursen. Detta hjälper också till att förhindra korruption av resursen eftersom vissa uppdateringar av en resurs endast kan utföras från en viss baspunkt.

Felhantering

En PATCH-begäran kan misslyckas om något av följande fel inträffar:

Felformat patchdokument

Servern returnerar ett 400-svar (dålig begäran) om PATCH-dokumentet inte formateras som krävs.

Patchdokument som inte stöds

Servern returnerar ett 415 (Unsupported Media Type )-svar med en Accept-Patch-svarsrubrik som innehåller stödda mediatyper när klienten skickar ett patchdokument i ett format som inte implementeras av servern. Detta informerar klienten om att PATCH-dokumentet som skickas av klienten inte kan tillämpas på den begärda resursen.

Obearbetbar begäran

Servern returnerar ett 422-svar (Obearbetbar enhet) när servern förstår PATCH-dokumentet men inte kan modifiera den begärda resursen antingen för att det gör att resursen blir ogiltig eller det resulterar i något annat feltillstånd.

Resursen hittades inte

Servern returnerar ett 404-svar (hittades ej) när PATCH-dokumentet inte kan tillämpas på en icke-existerande resurs.

Konfliktstat

Servern returnerar ett 409-svar (konflikt) när servern inte kan tillämpa en korrigeringsfil för resursens aktuella tillstånd.

Motstridig modifiering

Servern returnerar ett 412-svar (Förutsättning misslyckades) när förutsättningen som tillhandahålls av klienten med hjälp av rubriken If-Match eller If-Unmodified-Since misslyckas. Om inga förutsättningar tillhandahålls och det finns en motstridig ändring så returnerar servern ett 409 (konflikt) svar.

Samtidig modifiering

Servern returnerar ett 409-svar (konflikt) om PATCH-begäran till en viss resurs behöver appliceras i en viss ordning och servern inte kan hantera samtidiga PATCH-begäranden.

Säkerhetshänsyn

PATCH-begäran måste använda mekanismer som villkorliga förfrågningar som använder Etags och If-Match- begärans header för att säkerställa att data inte skadas under patchning. I händelse av ett misslyckande i en PATCH-begäran eller fel i kanalen eller en timeout, kan klienten använda en GET -begäran för att kontrollera resursens tillstånd. Servern måste se till att skadliga klienter inte använder PATCH-metoden för att förbruka överdrivna serverresurser.