हेडर में संदेश की सामग्री के अलावा बाकी सभी जानकारी होती है: कॉल करने वाला कौन है (Authorization), संदेश का प्रारूप क्या है (Content-Type), क्लाइंट को किस प्रारूप में संदेश वापस चाहिए (Accept), इसे कितने समय तक कैश किया जा सकता है (Cache-Control), इसका संस्करण क्या है (ETag) और दोबारा प्रयास कब करना है (Retry-After)। नाम केस-संवेदनशील नहीं होते; मान टेक्स्ट होते हैं।
अनुरोध या प्रतिक्रिया एक प्रारंभिक पंक्ति होती है, फिर प्रत्येक पंक्ति में एक हेडर, फिर एक खाली पंक्ति, और अंत में बॉडी। मध्यस्थ बॉडी को छुए बिना हेडर पढ़ते और जोड़ते हैं - एक प्रॉक्सी Via जोड़ता है, एक लोड बैलेंसर X-Forwarded-For जोड़ता है, और एक CDN अपनी कैश स्थिति जोड़ता है। कई व्यवहार जो API सुविधाओं की तरह दिखते हैं, वास्तव में हेडर के नियम हैं।
बॉडी पर दावा करना ही काफी है। कुछ सबसे महत्वपूर्ण बग केवल हेडर में ही होते हैं: 201 के बाद Location का न होना, Cache-Control जो एक निजी प्रतिक्रिया को CDN द्वारा कैश करने की अनुमति देता है, JSON बॉडी पर Content-Type का text/html होना। ये सभी बॉडी दावे पास कर लेते हैं।
डॉक्स पैनल में प्रत्येक प्रतिक्रिया बॉडी के बगल में अपने हेडर दिखाती है, और अभिकथन भाषा उन्हें हेडर के साथ पढ़ती है। <नाम> — GET /football/v1/standings.
सभी शब्द · परीक्षण तकनीकें · सभी 39 मॉक REST API
आखरी अपडेट