I veldesignet REST-udvikling er PUT og PATCH to HTTP-metoder til at opdatere ressourcer på serveren, men forskellen mellem PUT og PATCH i REST APIs ligger i, hvordan de udfører opdateringerne og de scenarier, hvor hver er mest passende. Begge metoder er designet til at ændre eksisterende data, men at forstå PUT og PATCH-forskellen i REST API hjælper udvikler med at træffe det bedste valg baseret på arten af den opdatering, de skal foretage. I dette blogindlæg udforsker vi PUT og PATCH-forskellen i REST API, fokuserer på PATCH vs. opdatering i REST, hvornår hver skal bruges, og giver vejledning om at vælge den rigtige metode til forskellige use cases.
Hvad er PUT i REST APIs?
For at forstå forskellen mellem PUT vs PATCH i REST APIs skal vi først vide, hvad PUT er. Ifølge Section 9.6 RFC 2616bruges PUT-metoden i REST API til at gemme den sendte enhed under den angivne Request-URI.
Hvis Request-URI henviser til en allerede eksisterende ressource, skal den sendte enhed betragtes som en modificeret version af ressourcen på oprindelig server. Hvis Request-URI ikke peger på en eksisterende ressource, og URI'en kan defineres som en ny ressource af den anmodende brugeragent, kan oprindelig server oprette ressourcen med denne URI.
Med andre ord bruges PUT-metoden til at opdatere en helt ressource på serveren. Dette gør PUT til en mere "fuldstændig" opdatering, som ofte bruges når en fuld erstatning af ressourcen er nødvendig.
PUT er derfor bedst til følgende use cases:
- Opdatering af en komplet ressource (f.eks. opdatering af en brugerprofil med helt nye oplysninger).
- Udskiftning af en helt vare eller post.
- Når ressourcens identitet er klar, og dens data skal fuldt opdateres.
In systems like Elasticsearchkræves idempotente operationer for at garantere datakonsistens. For eksempel sikrer opdatering af et dokument i Elasticsearch med PUT, at den samme anmodning kan gentages uden uønskede bivirkninger.
Hvad er PATCH i REST APIs?
Nu hvor vi har dækket PUT i REST APIs, lad os se på hvad PATCH er i REST APIs og hvordan det fungerer, før vi sammenligner PUT vs PATCH i REST APIs. Ifølge RFC 5789bruges PATCH-metoden i REST API til at anvende et sæt ændringer beskrevet i anmodningen på ressourcen identificeret af Request-URI.
Dette stemmer overens med PUT vs PATCH REST API-skelnen, hvor du kun sender de data, der skal ændres, og serveren anvender disse ændringer på den eksisterende ressource uden at ændre hele ressourcen. Udviklere opretter ofte patches for at repræsentere disse trinvise ændringer, hvilket sikrer minimal dataoverførsel og effektive opdateringer.
Derfor er PATCH-metoden i REST API bedre egnet til følgende use cases:
- Opdatering af kun en delmængde af felter i en ressource (f.eks. ændring af en brugers e-mailadresse eller telefonnummer). Et PATCH API-eksempel kunne omfatte at sende kun den nye e-mailadresse og lade andre felter være uberørte.
- Forbedring af ydeevne ved at minimere dataladningen.
- Når du vil opdatere en ressource trinvist i stedet for at erstatte den helt.
- Opret patches for at indkapsle specifikke feltændringer, som at ændre en brugers e-mail, uden at påvirke ikke-relaterede data.
For platforme som headless CMS som ofte håndterer komplekse indholdsstrukturer, kan brug af PATCH til mindre opdateringer, som at ændre et enkelt felt, reducere serverbelastning og forbedre ydeevnen.
Nu hvor vi har dækket disse to metoder, bør du have en god forståelse af hvad PUT og PATCH er i REST APIs. Men før vi går ind i forskellen mellem PUT vs PATCH i REST APIs, er vi nødt til at tale om idempotens i disse to metoder.
Idempotens i PUT vs. PATCH i REST APIs
I REST-API'er henviser idempotens til egenskaben ved en operation, som når den gentages flere gange med de samme input-data, resulterer i det samme resultat. Det betyder, at hvis du sender den samme anmodning flere gange, skal det have samme effekt på serveren, uanset hvor mange gange det udføres. Det er vigtig for at sikre stabilitet og forudsigelighed i en REST-API. Men hvordan er det relevant for PUT og PATCH-forskellen i REST-API'er?
PUT-metoden og idempotens
PUT-metoden i REST-API'er er altid idempotent, fordi den er designet til at erstatte hele ressourcen på en angivet URI med dataene fra anmodningen. Med andre ord, hvis du sender en PUT-anmodning flere gange med de samme ressourcedata, bliver resultatet altid det samme.
Hvorfor er PUT idempotent? Når du sender en PUT-anmodning, fortæller du i praksis serveren: "Dette er den komplette og nøjagtige tilstand, jeg ønsker for denne ressource." Uanset om du sender PUT-anmodningen en gang eller mange gange, vil den resulterende ressource altid være identisk.
Forestil dig for eksempel, at du opdaterer en brugers e-mailadresse. Hvis du sender den samme PUT-anmodning flere gange, ændres resultatet ikke, fordi ressourcen erstattes med de samme data hver gang.
Example:
| PUT /users/1{"username": "john_doe","email": "[email protected]"} |
Hvis du sender denne anmodning flere gange, bliver resultatet altid det samme:
| {"username": "john_doe","email": "[email protected]"} |
Selvom brugerens data allerede er sådan her, ændrer det intet at sende anmodningen igen. Den erstatter dataene med de samme data, så anmodningens effekt forbliver den samme, uanset hvor mange gange den gentages. Det er det, der gør PUT idempotent.
PATCH-metoden og idempotens
PATCH-metoden i REST-API'er er på den anden side generelt også idempotent, men med større fleksibilitet. Når du opretter patches, skal du sikre, at operationerne er idempotente (f.eks. at indstille en værdi) for at undgå utilsigtede bivirkninger fra gentagne anmodninger. Om PATCH er idempotent afhænger af operationen og de data, der bliver ændret.
Hvorfor er PATCH idempotent? For PATCH-anmodninger betyder idempotens, at hvis du anvender den samme patch flere gange, får du det samme resultat. Det er sandt, så længe patchen selv ikke forårsager yderligere bivirkninger eller ændringer ved gentagen anvendelse. Hvis du fortsætter med at anvende den samme patch med de samme data, bør resultatet være uændret efter første gang.
For eksempel, hvis du kun opdaterer en brugers e-mailadresse, vil det ikke ændre resultatet, selvom du sender den samme PATCH-anmodning flere gange efter første gang. Brugerens e-mailadresse forbliver den samme, og ressourcens tilstand ændres ikke.
PATCH REST-API-eksempel:
| PATCH /users/1{"email": "[email protected]"} |
Hvis e-mailadressen allerede var [email protected], vil det at anvende denne PATCH igen ikke resultere i nogen ændring, hvilket gør den idempotent.
PATCH kan dog også være ikke-idempotent i nogle tilfælde. For eksempel, hvis en PATCH-operation ændrer en tæller eller tilføjer elementer til en liste (som at øge et tal eller tilføje til et array), kan gentagen anvendelse af den samme PATCH føre til forskellige resultater. Det ville overtræde idempotens-egenskaben.
Ikke-idempotent REST-API PATCH-eksempel:
| PATCH /counter/1{"increment": 1} |
Hvis du anvender denne PATCH gentagne gange, vil tælleren blive ved med at stige, hvilket resulterer i forskellige værdier hver gang. Det er ikke idempotent, fordi resultatet ændrer sig ved hver anvendelse.
Nu hvor du kender det vigtigste, kan vi kigge på nogle eksempelscenarier for bedre at forstå forskellen mellem PUT og PATCH i REST-API'er.
Eksempelscenarier: PUT vs PATCH i REST APIs
Lad os se på forskellen mellem PUT og PATCH med eksempler, herunder både idempotente og ikke-idempotente operationer.
Scenario 1: PUT-anmodning – Udskiftning af en hel ressource
Forestil dig et REST-API-endpoint til håndtering af produkter i et e-commerce-system. Du skal opdatere alle detaljer for et produkt, herunder navn, pris og beskrivelse. Det er et typisk eksempel på PUT vs PATCH, hvor PUT bruges til at erstatte hele produktressourcen.
Initial Product:
| GET /products/1001{"id": 1001,"name": "Laptop","price": 999.99,"description": "A powerful laptop."} |
Du vil opdatere produktets pris og beskrivelse. Du sender en PUT-anmodning med hele ressourcen:
PUT Request:
| PUT /products/1001{"id": 1001,"name": "Laptop","price": 899.99,"description": "A discounted powerful laptop."} |
Hvis du sender denne PUT-request én gang eller flere gange, bliver resultatet altid det samme. Produktdetaljerne opdateres med den nye pris og beskrivelse, og samme resultat opstår hver gang. Det sikrer PUT's idempotente egenskab.
Resultat (Efter PUT-request):
| {"id": 1001,"name": "Laptop","price": 899.99,"description": "A discounted powerful laptop."} |
Scenario 2: PATCH-request - Opdatering af del af en ressource
Lad os nu se på en PATCH-request til at opdatere kun en del af produktets detaljer, såsom beskrivelsen. PATCH API eksempel: hvis du vil ændre produktbeskrivelsen men ikke prisen, er PATCH det bedre valg. For at implementere dette opretter du patches, der kun indeholder felterne, der skal ændres, såsom beskrivelsen i dette API REST PATCH-eksempel.
Initial Product:
| GET /products/1001{"id": 1001,"name": "Laptop","price": 999.99,"description": "A powerful laptop."} |
PATCH Request:
| PATCH /products/1001{"description": "A lightweight, powerful laptop."} |
Når du sender denne PATCH-request, opdateres kun beskrivelsesfeltet. Hvis du sender samme PATCH-request flere gange, forbliver beskrivelsen uændret efter den første opdatering, hvilket gør requestet idempotent.
Resultat (Efter PATCH-request):
| {"id": 1001,"name": "Laptop","price": 999.99,"description": "A lightweight, powerful laptop."} |
Hvis du anvender samme PATCH igen, vil produktbeskrivelsen stadig være den samme som efter første PATCH. Resultatet er konsistent, hvilket gør PATCH idempotent i dette scenario.
Scenario 3: PATCH-request - Ikke-idempotent operation
Lad os se på en ikke-idempotent PATCH-operation. Antag, at der er et endpoint for en brugers pungbalance, og du vil øge balancen. En eksempelforskel mellem PUT og PATCH kan illustreres her: PATCH lægger en værdi til balancen hver gang
Initial Wallet:
| GET /users/1/wallet{"id": 1,"balance": 100.00} |
PATCH Request:
| PATCH /users/1/wallet{"increment": 50.00} |
Denne PATCH-request øger pungbalancen med 50 dollars. Hvis du sender denne PATCH-request flere gange, stiger balancen med hver PATCH, hvilket fører til et anderledes resultat hver gang. Det er ikke-idempotent, fordi gentagne requests med samme data producerer forskellige resultater.
Resultat (Efter første PATCH-request):
| {“id”: 1,”balance”: 150.00} |
Resultat (Efter anden PATCH-request):
| {“id”: 1,”balance”: 200.00} |
Her er PATCH ikke idempotent, fordi gentagne requests med samme data producerer forskellige resultater.
Opsummering: Vigtigste forskelle mellem PUT vs PATCH i REST APIs
Nøgleforskellen mellem PUT vs PATCH i REST API ligger i, hvordan de håndterer opdateringer. PUT erstatter hele ressourcen, så alle manglende felter bliver slettet, hvilket kan føre til datatab. Det er derfor, udviklere opretter patches til delvise opdateringer - for at undgå at overwrite uændrede felter og bevare dataintegritet.
Det gør PATCH mere effektiv til delvise opdateringer. Et PATCH API-eksempel er, at hvis du vil opdatere kun en brugers email, vil patches kun sende emailfeltet, i modsætning til en PUT-request, der ville kræve alle brugerdata.
Med PUT kræves hele datapakken. Det betyder, at alle felter skal sendes, og alle manglende felter slettes. PATCH sender derimod kun de felter, der skal opdateres, hvilket gør det mere effektivt, især for store ressourcer med minimale ændringer. PATCH-metoden i REST API tillader mere målrettede og mindre requests, hvilket reducerer dataoverførsel.
Både PUT og PATCH er idempotente. Det betyder, at gentagne requestet vil give samme resultat. PUT er dog mere forudsigeligt, da det erstatter hele ressourcen. PATCH, når det bruges til at ændre kun specificerede felter, kan føre til forskellige resultater afhængig af, hvordan serveren håndterer opdateringer.
For eksempel, hvis en PATCH øger en tæller, kunne gentagne requests føre til forskellige resultater. Ikke desto mindre kan PATCH API-operationer designes til også at være idempotente.
Konklusionen på PUT og PATCH-forskellen i REST API kommer ned til arten af opdateringerne: PATCH bruges til delvise ændringer, mens PUT bruges til fuldstændig ressourceerstatning. Begge er idempotente, men PATCH kan være mere kompleks.
Final Thoughts
Både PUT og PATCH er fundamentale HTTP-metoder i REST API-design, men de tjener forskellige formål, hvilket er essensen af PUT og PATCH-forskellen i REST API. Du kan betydeligt forbedre effektiviteten, klarhed og funktionalitet af dit API ved at forstå forskellen mellem PUT og PATCH med de eksempler, vi dækkede tidligere i denne artikel. Ved at vælge den korrekte metode (PATCH vs opdatering REST) baseret på dit use case, kan du gøre dit API mere effektivt, vedligeholdeligt og brugervenligt. Overvej altid arten af opdateringen - om den er fuldstændig eller delvis - samt påvirkningen på performance og dataintegritet, og vælg den metode, der bedst passer dine behov.
