REST API क्या है? प्रतिबंध, संसाधन, और डिज़ाइन

स्क्रेपलेस स्क्रेपिंग API कार्य-विशिष्ट HTTP इंटरफ़ेस प्रदान करता है जो अनुप्रयोग कार्यप्रवाह के लिए संरचित सार्वजनिक वेब डेटा लौटाता है।

REST API परिभाषित

REST API एक एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस है जिसे प्रतिनिधिमंडल राज्य स्थानांतरण आर्किटेक्चरल स्टाइल के अनुसार डिज़ाइन किया गया है। REST वितरण किए गए हायपरमीडिया सिस्टम में घटकों के लिए प्रतिबंधों का वर्णन करता है। यह JSON, एक URL पैटर्न, या एक विशेष प्रोग्रामिंग भाषा की आवश्यकता नहीं होती। वेब APIs सामान्यतः HTTP के माध्यम से REST विचारों को लागू करते हैं क्योंकि HTTP पहले से ही पहचान, विधियाँ, प्रतिनिधित्व, मेटाडेटा, कैशिंग, और मध्यस्थ प्रदान करता है।

केंद्रिय抽象 एक संसाधन है: एक वैकल्पिक चीज जिसका समय के साथ पहचान की जा सकती है। एक सर्वर संसाधन की स्थिति का प्रतिनिधित्व भेजता है, जैसे कि JSON या XML दस्तावेज़, इसके आंतरिक डेटाबेस वस्तु को स्थानांतरित करने के बजाय। क्लाइंट उस प्रतिनिधित्व को व्याख्या करता है और इंटरफ़ेस अर्थशास्त्र का पालन करता है। मूल REST आर्किटेक्चरल विवरण व्याख्या करता है कि कैसे प्रतिबंध दृश्यता, स्केलेबिलिटी, और स्वतंत्र विकास का समर्थन करते हैं।

व्यवहार में REST प्रतिबंध

REST API क्या है इसके पीछे के मैकेनिक्स एक से अधिक सॉफ़्टवेयर या नेटवर्क सीमा को पार करते हैं। प्रत्येक चरण का नामकरण प्रदर्शन, शुद्धता, और सुरक्षा समीक्षाओं को ठोस बनाता है।

क्लाइंट-सरवर और स्टेटलेस इंटरैक्शन

क्लाइंट की चिंताओं को सर्वर डेटा और व्यवहार से अलग किया गया है। प्रत्येक अनुरोध में इसे समझने के लिए आवश्यक जानकारी होती है, न कि पहले के अनुरोध से छिपी वार्तालाप स्थिति पर निर्भर करते हुए। प्रमाणीकरण की स्थिति या संग्रहीत संसाधन मौजूद हो सकते हैं; प्रतिबंध एक बिना मेमोरी वाले सर्वर की आवश्यकता नहीं करता।

कैश और लेयर्ड सिस्टम

प्रतिक्रियाएँ निर्धारित करती हैं कि क्या उन्हें फिर से उपयोग किया जा सकता है। गेटवे, प्रॉक्सी, और अन्य मध्यस्थ क्लाइंट और मूल के बीच बैठ सकते हैं बिना उस इंटरफ़ेस को बदले जो क्लाइंट देखता है। सही मेटाडेटा एक कैश को दोहराए गए काम को कम करने में मदद करता है जबकि प्रतिनिधित्व अर्थशास्त्र को बनाए रखता है।

एक समान इंटरफ़ेस और वैकल्पिक कोड डिमांड पर

घटक एक लगातार सेट के माध्यम से इंटरैक्ट करते हैं: पहचाने गए संसाधन, प्रतिनिधित्व, आत्म-व्याख्यात्मक संदेश, और हायपरमीडिया नियंत्रण। कोड डिमांड पर वैकल्पिक प्रतिबंध है, जो कार्यान्वयन करने योग्य कोड को क्लाइंट व्यवहार को बढ़ाने की अनुमति देता है जब सिस्टम इसे उपयोग करने का चुनाव करता है।

REST अवधारणाएँ और उनके HTTP व्याकरण

टीमें अक्सर एक लेबल पर सहमति देती हैं जबकि अलग-अलग व्यवहार मानते हैं। ये पंक्तियाँ REST API क्या है को स्पष्ट अनुबंध और संचालन प्रश्नों में बदल देती हैं।

REST APIs कहाँ बेहतर काम करते हैं

REST API क्या है को अपनाने या अनुकूलित करने का सबसे मजबूत कारण कार्यप्रवाह के साथ एक मापनीय फिट है। ये परिदृश्य उस फिट का वर्णन करते हैं बिना इस शब्द को एक सार्वभौमिक डिफ़ॉल्ट के रूप में मानते हुए।

REST API को कैसे डिज़ाइन या मूल्यांकित करें

डोमेन संसाधनों और उनके पहचानकर्ताओं के साथ प्रारंभ करें, फिर प्रतिनिधित्व और संक्रमण को परिभाषित करें। हर व्यावसायिक क्रिया को एक मनमाने क्रिया के आकार के URL में बदलने से बचें। कुछ ऑपरेशन मूल संसाधन परिवर्तनों के लिए स्वच्छता से मानचित्रित नहीं होते हैं; वे अभी भी संसाधनों, नौकरियों या आदेशों के रूप में मॉडल किए जा सकते हैं, लेकिन स्पष्टता कॉस्मेटिक शुद्धता से अधिक महत्वपूर्ण है।

HTTP अर्थव्यवस्थाओं का लगातार उपयोग करें। वर्तमान HTTP अर्थव्यवस्था मानक विधि गुण, स्थिति कोड, क्षेत्र और प्रतिनिधित्व अवधारणाओं को परिभाषित करता है। एक सुरक्षित विधि को असुरक्षित व्यावसायिक परिवर्तन करने के लिए प्रलेखित नहीं किया जाना चाहिए। कैश मेटाडेटा, स्थितिक अनुरोध और सामग्री वार्ता वास्तविक व्यवहार को दर्शाना चाहिए न कि कॉपी की गई हेडर को।

डिज़ाइन त्रुटियों और पृष्ठांकन को अनुबंध के पहले-श्रेणी भागों के रूप में। ग्राहकों को स्थिर त्रुटि पहचानकर्ताओं, मानव-पठनीय विस्तार, क्षेत्र-स्तरीय सत्यापन संदर्भ, और घटनाओं को संबंधित करने का एक मार्ग चाहिए। बड़े संग्रहों को निर्धारक क्रम और निरंतरता नियमों की आवश्यकता होती है जो डेटा परिवर्तन के दौरान सही रहती हैं। प्राधिकरण को प्रत्येक संसाधन और ऑपरेशन के लिए मूल्यांकन किया जाना चाहिए, न कि केवल पहचानकर्ता के स्वामित्व से अनुमान लगाया जाना चाहिए।

सामान्य REST API डिज़ाइन त्रुटियाँ

• किसी भी JSON-over-HTTP इंटरफ़ेस को REST कहना। परिवहन और मीडिया प्रकार यह साबित नहीं करते कि आर्किटेक्चरल प्रतिबंध मौजूद हैं।
• स्टेटलेसनेस को बिना संग्रहीत डेटा के भ्रमित करना। REST सर्वर संसाधनों को संग्रहित करते हैं; वे बाद के अनुरोधों को व्याख्या करने के लिए आवश्यक छिपे हुए संवादात्मक संदर्भ से बचते हैं।
• प्रत्येक परिणाम के लिए एक स्थिति वापस करना। ग्राहकों को उपयोगी अर्थ से हटाना जब सत्यापन, प्राधिकरण, अनुपस्थिति, संघर्ष, और सर्वर विफलता समान दिखते हैं।
• एक मॉडल के बिना कैश हेडर का उपयोग करना। गलत ताजगी या वेलिडेटर्स बासी डेटा सर्व कर सकते हैं या सुरक्षित पुन: उपयोग रोक सकते हैं।
• संस्करण परिवर्तनों के दौरान पहचानकर्ताओं को तोड़ना। स्थिर संसाधन पहचान और स्पष्ट संगतता नीति सजावटी URL परंपराओं की तुलना में अधिक मायने रखती है।

डेटा संग्रह प्रणालियों में REST APIs

एक REST-शैली डेटा स्रोत अक्सर पृष्ठित संग्रह और आइटम संसाधनों को उजागर करता है। एक संग्रहकर्ता को प्रलेखित निरंतरता लिंक या कर्सर्स का पालन करना चाहिए, प्रतिक्रिया मेटाडेटा रिकॉर्ड करना चाहिए, प्रतिनिधित्व को मान्य करना चाहिए, और स्रोत पहचानकर्ताओं को बनाए रखना चाहिए। इसे API द्वारा जारी किए गए निरंतरता नियंत्रण के बिना बिना प्रलेखित पृष्ठ अंकगणित को आविष्कार नहीं करना चाहिए।

स्थितिक अनुरोधों से संग्रह को पुनः प्राप्त करने के लिए अधिक प्रभावी बनाया जा सकता है जब सेवा वेलिडेटर्स प्रकाशित करती है। ग्राहक पूछता है कि क्या प्रतिनिधित्व में परिवर्तन आया है और केवल आवश्यक होने पर एक शरीर को प्रोसेस करता है। यह ट्रांसफर और मूल काम को घटा सकता है, लेकिन केवल तब जब स्रोत अनुबंध अर्थव्यवस्थाओं का दस्तावेज करता है और संग्रहकर्ता संबंधित संसाधन के साथ वेलिडेटर्स संग्रहीत करता है।

जब आवश्यक सार्वजनिक डेटा केवल एक प्रदर्शित पृष्ठ के माध्यम से उपलब्ध होता है, तो एक ब्राउज़र या स्क्रेपिंग इंटरफ़ेस अधिग्रहण परत प्रदान कर सकता है। उस चरण को सामान्यीकृत आंतरिक REST सेवा से अलग रखना चाहिए जो डाउनस्ट्रीम उपभोक्ताओं को उजागर करती है। विभाजन स्रोत-विशिष्ट रेंडरिंग और पार्सिंग को बदलने की अनुमति देता है बिना हर उपभोक्ता को बदलने के लिए मजबूर किए।

REST API समीक्षा चेकलिस्ट

इन चेक का उपयोग करें ताकि What Is a REST API परिभाषा को कार्यान्वयन साक्ष्य में बदल सके जिसे एक डेवलपर, ऑपरेटर, या समीक्षक पुनः उत्पन्न कर सके।

1. सीमा को फिर से बताएं। REST API के लिए, कॉलर, प्रदाता, पथ, और वह सटीक घटना को पहचानें जो एक पूर्ण परिणाम को चिह्नित करता है।
2. केंद्रीय दावे को सत्यापित करें। इस कथन की पुष्टि करें जो कार्यान्वयन और इसके दस्तावेज़ के साथ है: REST एक आर्किटेक्चरल स्टाइल है। एक REST API नेटवर्क इंटरैक्शन पर प्रतिबंध लगाए बिना एक एंडपॉइंट टेम्पलेट या डेटा प्रारूप को prescribe करता है।
3. यांत्रिकी का पता लगाएं। क्लाइंट-सेर्वर और Stateless इंटरैक्शन, कैश और स्तरित प्रणाली, समान इंटरफ़ेस और आवश्यकता पर वैकल्पिक कोड पर ध्यान दें, और रिकॉर्ड करें कि प्रत्येक चरण के लिए कौन-सा घटक जिम्मेदार है।
4. नज़दीकी भेद को जांचें। दस्तावेज करें कि संसाधन पहचानकर्ता का अर्थ इस प्रणाली में "कल्पनाशील संसाधन को नामित करता है।"
5. एक प्रतिनिधि उपयोग मामला का परीक्षण करें। वास्तविक डेटा, स्थान, मात्रा, और अनुमति सीमाओं के साथ संसाधन-उन्मुख सेवाओं का उपयोग करें।
6. एक ज्ञात त्रुटि के खिलाफ सुरक्षा करें। "किसी भी JSON-over-HTTP इंटरफ़ेस को REST कहना।" की समीक्षा करें और एक स्वीकृति चेक जोड़ें जो इसे पकड़ता है।
7. कार्यभार को सीमित करें। क्या एक REST API है, जिसमें लागू होने पर payload, concurrency, execution time और stored output के लिए विषय के अनुसार सीमाएं सेट करें।
8. निर्णय रिकॉर्ड करें। यह समझाएं कि एक REST API इस सीमा में क्यों फिट बैठता है और वह सबूत बताएं जो बाद में एक अलग दृष्टिकोण को सही ठहराएगा।

निष्कर्ष

एक REST API को डिज़ाइन के एक परीक्षण योग्य भाग का वर्णन करना चाहिए न कि पड़ोसी व्यवहार के लिए एक ढीला लेबल के रूप में कार्य करना चाहिए। समीक्षा को इस केंद्रीय निर्णय को बनाए रखना चाहिए: REST एक वास्तुशिल्प शैली है। एक REST API नेटवर्क पर बातचीत को सीमा देता है न कि एक एंडपॉइंट टेम्पलेट या डेटा प्रारूप को निर्धारित करता है। इसे किसी भी json-over-http इंटरफेस को REST कहने से भी बचाना चाहिए। और एक REST API के लिए पहुँच को या नेटवर्क के लिए दस्तावेजित नीति के भीतर रखना चाहिए।