पाठ 10 / 27
Caching और Conditional Requests (ETag)
अपरिवर्तित डेटा दोबारा भेजने से बचने के लिए ETag और If-None-Match और caching के लिए Cache-Control उपयोग करें।
पूछें "क्या यह बदला?"
ETag किसी प्रतिनिधित्व का अपारदर्शी version tag है (अक्सर hash)। Server ETag: "abc" भेजता है; बाद में client वही अनुरोध If-None-Match: "abc" के साथ दोहराता है। Resource न बदला हो तो server बिना body के 304 Not Modified देता है, जिससे bandwidth और समय बचता है। वही tags writes के लिए optimistic concurrency देते हैं: client PUT/PATCH के साथ If-Match: "abc" भेजता है, और किसी और के पहले resource बदलने पर server 412 Precondition Failed लौटाता है, जिससे खोए अपडेट रुकते हैं। Cache-Control (max-age, private, no-store) browsers और CDNs को बताता है कि response कितनी देर दोबारा उपयोग करें; व्यक्तिगत डेटा वाले responses को private या no-store चिह्नित करें।
असली API से 304, चलाकर
मैंने यह केवल Python standard library से बने छोटे असली HTTP API पर चलाया (पूरा कोड केस स्टडी में)। पहला GET item और एक ETag लौटाता है। उसी tag को If-None-Match के रूप में देकर दोहराने पर बिना body (None) के 304 मिलता है।
# uses srv, base and call() from the runnable demo in the case study
s, h, b = call("GET", "/v2/items/1"); tag = h["ETag"]; print(s, b, "has etag:", tag.startswith('"'))
s, h2, b2 = call("GET", "/v2/items/1", headers={"If-None-Match": tag}); print(s, b2)
Output:
200 {'id': 1, 'first_name': 'Asha', 'last_name': 'Rao', 'plan': 'pro'} has etag: True
304 Noneखोए अपडेट रोकने को If-Match उपयोग करें
दो लोग एक ही record बदलते हैं: If-Match के बिना दूसरा save चुपचाप पहले को overwrite करता है। उसके साथ दूसरे को साफ़ 412 मिलता है और वह फिर लोड करके मिला सकता है।
त्वरित जाँच: `304 Not Modified` client को क्या बताता है?
- Cached copy अब भी वैध है; कोई body नहीं भेजी जाती
- Resource हटा दिया गया
- अनुरोध विफल हुआ
- Credentials ग़लत हैं
Answer
Cached copy अब भी वैध है; कोई body नहीं भेजी जाती — मेल खाते ETag वाला conditional GET server को body छोड़ने देता है।