Cachning

Cachning är ett av de sex kraven enligt restprinciperna (se vidare En introduktion till RESTÖppnas i ny flik), ett API behöver överväga för att benämnas som RESTful. Kravet innebär inte att all data faktiskt behöver cachas, utan att resurser som tjänar på att mellanlagras identifieras och märks upp enligt nedan förslag. 

Begäran

När en konsument begär en resursrepresentation, går begäran igenom en cache eller en serie cacheminnen (lokal cache, proxycache eller omvänd proxy) mot den tjänst som är värd för resursen.

Genom att använda HTTP-headers anger en serverkälla om ett svar kan cachelagras och i så fall av vem och hur länge. Att optimera nätverket med cachelagring förbättras den övergripande servicekvaliteten på följande sätt:

• minskar bandbredden 
• minskar latensen 
• minskar belastningen på servrar 
• kan dölja nätverksfel.

Cachelagring i REST-API:er

Att cachelagra är en av de arkitektoniska begränsningarna för REST, och beskrivs i RFC 9111Öppnas i ny flik.

1. GET-request BÖR (CAC.01) kunna cachelagras som standard. Vanligtvis behandlar webbläsare alla GET-request cachelagrade.  
2. POST-request kan inte cachelagras som standard men kan cachelagras som antingen en Cache-Control header eller en Expires header med en instruktion (för att uttryckligen tillåta cachelagring) läggs till i svaret.
3. Svar på PUT och DELETE förfrågningar kan inte cachelagras alls. 

Det finns två huvudsakliga HTTP-cache headers: Cache-Control och Expires . 
 

Cache-Control

Cache-Control meddelar om klienten ska cachelagra.

Exempel: Alla delar av nätverket ska cachelagra innehållet i en timme: 

Cache-Control: public, max-age=3600, must-revalidate

Expires

Expires instruktionen, när det används tillsammans med Cache-Control, anger ett datum då innehållet anses inaktuellt. Om både Expires och Cache-Control anges har Cache-Control företräde.

Exempel:

Cache-Control: public
Expires: Mon, 25 Jun 2019 21:31:12 GMT

Tidpunkt i Expires skrivs alltid i GMT.

Övriga HTTP-cacherubriker

Andra förekommande HTTP-cacherubriker beskrivs nedan översiktligt.

Age

Age headern berättar hur läng tid som förflutit sedan svaret genererades eller validerades senast av servern.

Pragma

Pragma‎‎ är en HTTP/1.0-header. Pragma‎‎: no-cache ‎är som Cache-Control: no-cache genom att det tvingar cachen att skicka begäran till serverkällan för validering innan en cachekopia lämnas. Pragma‎‎ är dock inte specificerad för HTTP-svar och är därför inte en tillförlitlig ersättning för det allmänna HTTP/1.1 Cache-Control headern.‎

Pragma‎‎ bör endast användas för bakåtkompatibilitet med HTTP/1.0-cache där Cache-Control HTTP/1.1-headern ännu inte finns.‎

Warning

Den generella HTTP headern Warning innehåller information om eventuella problem med meddelandets status. Mer än en Warning header kan visas i ett svar.

Warning headers attribut kan i allmänhet tillämpas på alla meddelanden, men vissa varningskoder är specifika för cache och kan endast tillämpas på svarsmeddelanden.‎

ETag

En ETag (entitetstagg) kan användas i responseheader för entitetsdata. En ETag är en sträng som anger en resursversion – varje gång en resurs ändras ändras även ETag. ETag ska cachelagras som en del av datat hos klienten. ETag är främst användbart för att spara bandbredd.

GET /organisationer/5560125790

HTTP/1.1 200 OK 
... 
Cache-Control: max-age=600, private 
Content-Type: text/json;
ETag: "2147483648"
 Content-Length: ... 
 { "organisationsnummer": "5560125790", "namn": "Aktiebolaget Volvo", ... }

Klienten konstruerar en GET-begäran som innehåller den ETag för närvarande cachelagrade versionen av resursen som refereras i ett If-None-Match HTTP-header:

GET /foretagsinformation/v1/organisationer/5560125790
If-None-Match: "2147483648"

ETag matchar‎

Returnera ett HTTP-response med en tom meddelandetext och en statuskod på ‎304 Not Modified.

ETag matchar inte

Data har ändrats och webb-API:et bör returnera ett HTTP-response med nya data i meddelande body och en statuskod för ‎200 OK.