Ad Code

REST API क्या है What is REST API In Hindi

REST API क्या है What is REST API In Hindi


REST क्या है

REST का प्रतिनिधित्व स्टेटिक ट्रांसफर के लिए किया जाता है। यह वितरित हाइपरमीडिया प्रणालियों के लिए स्थापत्य शैली है और पहली बार 2000 में रॉय फील्डिंग द्वारा अपने प्रसिद्ध शोध प्रबंध में प्रस्तुत किया गया था।

किसी भी अन्य स्थापत्य शैली की तरह, REST में भी इसकी 6 मार्गदर्शक बाधाएँ हैं, जिन्हें यदि किसी इंटरफ़ेस को RESTful के रूप में संदर्भित करने की आवश्यकता है, तो संतुष्ट होना चाहिए। ये सिद्धांत नीचे सूचीबद्ध हैं।


REST के मार्गदर्शक सिद्धांत

क्लाइंट-सर्वर - डेटा स्टोरेज चिंताओं से उपयोगकर्ता इंटरफ़ेस चिंताओं को अलग करके, हम कई प्लेटफार्मों पर उपयोगकर्ता इंटरफ़ेस की पोर्टेबिलिटी में सुधार करते हैं और सर्वर घटकों को सरल करके स्केलेबिलिटी में सुधार करते हैं।

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

कैशेबल - कैश की कमी के कारण अनुरोध की प्रतिक्रिया के भीतर डेटा को स्पष्ट रूप से या स्पष्ट रूप से कैचेबल या गैर-कैचीबल के रूप में लेबल किया जा सकता है। यदि कोई प्रतिक्रिया अस्वीकार्य है, तो एक क्लाइंट कैश को बाद में, समान अनुरोधों के लिए उस प्रतिक्रिया डेटा का पुन: उपयोग करने का अधिकार दिया जाता है।

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

लेयर्ड सिस्टम - लेयर्ड सिस्टम स्टाइल एक आर्किटेक्चर को घटक व्यवहार को बाध्य करके पदानुक्रमित परतों से बना होता है, जैसे कि प्रत्येक घटक उस तत्काल परत से परे "देख" नहीं सकता जिसके साथ वे बातचीत कर रहे हैं।

कोड ऑन डिमांड (वैकल्पिक) - REST एप्लेट या स्क्रिप्ट के रूप में कोड को डाउनलोड और निष्पादित करके क्लाइंट कार्यक्षमता को बढ़ाने की अनुमति देता है। यह पूर्व-कार्यान्वित होने के लिए आवश्यक सुविधाओं की संख्या को कम करके ग्राहकों को सरल बनाता है।


संसाधन

REST में सूचना का मुख्य अमूर्त संसाधन है। कोई भी जानकारी जिसे नाम दिया जा सकता है वह एक संसाधन हो सकता है: एक दस्तावेज या छवि, एक अस्थायी सेवा, अन्य संसाधनों का एक संग्रह, एक गैर-आभासी वस्तु (जैसे एक व्यक्ति), और इसी तरह। REST घटकों के बीच सहभागिता में शामिल विशेष संसाधन की पहचान करने के लिए एक संसाधन पहचानकर्ता का उपयोग करता है।

किसी विशेष टाइमस्टैम्प पर संसाधन की स्थिति को संसाधन प्रतिनिधित्व के रूप में जाना जाता है। एक प्रतिनिधित्व में डेटा होता है, मेटाडेटा डेटा और हाइपरमीडिया लिंक का वर्णन करता है जो ग्राहकों को अगले वांछित राज्य में संक्रमण में मदद कर सकता है।

एक प्रतिनिधित्व का डेटा प्रारूप एक मीडिया प्रकार के रूप में जाना जाता है। मीडिया प्रकार एक विनिर्देशन की पहचान करता है जो परिभाषित करता है कि प्रतिनिधित्व कैसे संसाधित किया जाना है। सही मायने में RESTful API हाइपरटेक्स्ट की तरह दिखता है। सूचना की प्रत्येक पता योग्य इकाई एक पता लगाती है, या तो स्पष्ट रूप से (जैसे, लिंक और आईडी विशेषताएँ) या अंतर्निहित रूप से (जैसे, मीडिया प्रकार की परिभाषा और प्रतिनिधित्व संरचना से व्युत्पन्न)।


रॉय फील्डिंग के अनुसार:

हाइपरटेक्स्ट (या हाइपरमीडिया) का अर्थ है सूचना की एक साथ प्रस्तुति और नियंत्रण जैसे कि सूचना वह खर्च बन जाती है जिसके माध्यम से उपयोगकर्ता (या ऑटोमेटन) विकल्प प्राप्त करता है और कार्यों का चयन करता है। याद रखें कि हाइपरटेक्स्ट को ब्राउज़र पर HTML (या XML या JSON) होने की आवश्यकता नहीं है। जब वे डेटा प्रारूप और संबंध प्रकारों को समझते हैं तो मशीनें लिंक का अनुसरण कर सकती हैं।

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

प्रत्येक मीडिया प्रकार एक डिफ़ॉल्ट प्रसंस्करण मॉडल को परिभाषित करता है। उदाहरण के लिए, HTML हाइपरटेक्स्ट और प्रत्येक तत्व के आस-पास ब्राउज़र व्यवहार के लिए एक प्रतिपादन प्रक्रिया को परिभाषित करता है। इसका संसाधन विधियों GET / PUT / POST / DELETE / ... से कोई संबंध नहीं है, इस तथ्य के अलावा कि कुछ मीडिया प्रकार के तत्व एक प्रक्रिया मॉडल को परिभाषित करेंगे, जो "a href विशेषता वाले एंकर तत्वों को हाइपरटेक्स्ट लिंक बनाते हैं जो चयनित होने पर बनाते हैं" CDRI- एन्कोडेड href विशेषता के अनुरूप URI पर पुनर्प्राप्ति अनुरोध (GET) लागू करता है। 


संसाधन विधियाँ

वांछित परिवर्तन करने के लिए उपयोग की जाने वाली संसाधन विधियाँ REST से जुड़ी एक और महत्वपूर्ण बात है। बड़ी संख्या में लोग HTTP GET / PUT / POST / DELETE विधियों में संसाधन विधियों को गलत तरीके से संबंधित करते हैं।

रॉय फील्डिंग ने कभी भी किसी भी सिफारिश का उल्लेख नहीं किया कि किस स्थिति में किस पद्धति का उपयोग किया जाए। सभी वह जोर देते हैं कि यह एक समान इंटरफ़ेस होना चाहिए। यदि आप तय करते हैं कि HTTP POST का उपयोग किसी संसाधन को अपडेट करने के लिए किया जाएगा - बजाय ज्यादातर लोग HTTP PUT की अनुशंसा करते हैं - यह ठीक है और एप्लिकेशन इंटरफ़ेस RESTful होगा।

आदर्श रूप से, संसाधन राज्य को बदलने के लिए आवश्यक हर चीज उस संसाधन के लिए एपीआई प्रतिक्रिया का हिस्सा होगी - जिसमें विधियां भी शामिल हैं और वे किस राज्य में प्रतिनिधित्व को छोड़ देंगे।

REST API को प्रारंभिक URI (बुकमार्क) से परे कोई पूर्व ज्ञान के साथ दर्ज किया जाना चाहिए और मानकीकृत मीडिया प्रकारों का सेट जो कि लक्षित दर्शकों के लिए उपयुक्त हो (अर्थात, किसी भी क्लाइंट द्वारा समझा जा सकता है जो एपीआई का उपयोग कर सकता है)। उस बिंदु से, सभी एप्लिकेशन स्टेट ट्रांज़िशन को क्लाइंट-प्रदान किए गए विकल्पों के क्लाइंट चयन द्वारा संचालित किया जाना चाहिए जो प्राप्त अभ्यावेदन में मौजूद हैं या उन अभ्यावेदन के उपयोगकर्ता के हेरफेर द्वारा निहित है। संक्रमण को मीडिया प्रकारों और संसाधन संचार तंत्र के ग्राहक के ज्ञान के आधार पर (या सीमित) निर्धारित किया जा सकता है, दोनों को ही मक्खी (जैसे, कोड-ऑन-डिमांड) में सुधार किया जा सकता है।

[यहाँ असफलता का अर्थ है कि बाहर की सूचना हाइपरटेक्स्ट के बजाय बातचीत चला रही है।]

एक और चीज़ जो आपको RESTful API के निर्माण में मदद करेगी, वह यह है कि क्वेरी आधारित API परिणामों को सारांश जानकारी के साथ लिंक की एक सूची द्वारा दर्शाया जाना चाहिए, मूल संसाधन अभ्यावेदन के सरणियों द्वारा नहीं, क्योंकि क्वेरी संसाधनों की पहचान का विकल्प नहीं है।


बाकी और HTTP समान नहीं हैं !!

बहुत सारे लोग HTTP को REST से तुलना करना पसंद करते हैं। REST और HTTP समान नहीं हैं।

बाकी! = HTTP

हालाँकि, क्योंकि REST भी वेब (इंटरनेट) को अधिक सुव्यवस्थित और मानक बनाने का इरादा रखता है, वह REST सिद्धांतों का अधिक सख्ती से उपयोग करने की वकालत करता है। और वह वही है जहाँ से लोग REST की तुलना वेब (HTTP) से करने की कोशिश करते हैं। रॉय फील्डिंग, अपने शोध प्रबंध में, कहीं भी किसी भी प्रोटोकॉल और वरीयता और HTTP सहित कार्यान्वयन निर्देश का उल्लेख किया है। तब तक, आप REST के 6 मार्गदर्शक सिद्धांतों का सम्मान कर रहे हैं, आप अपने इंटरफ़ेस को RESTful कह सकते हैं।

सबसे सरल शब्दों में, REST वास्तु शैली में, डेटा और कार्यक्षमता को संसाधन माना जाता है और यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) का उपयोग करके एक्सेस किया जाता है। सरल, सुव्यवस्थित संचालन के सेट का उपयोग करके संसाधनों पर कार्य किया जाता है। क्लाइंट और सर्वर एक मानकीकृत इंटरफ़ेस और प्रोटोकॉल का उपयोग करके संसाधनों का प्रतिनिधित्व करते हैं - आमतौर पर HTTP।

संसाधनों को उनके प्रतिनिधित्व से अलग कर दिया जाता है, ताकि उनकी सामग्री को विभिन्न स्वरूपों, जैसे HTML, XML, सादे पाठ, PDF, JPEG, JSON और अन्य में एक्सेस किया जा सके। संसाधन के बारे में मेटाडेटा उपलब्ध है और इसका उपयोग किया जाता है, उदाहरण के लिए, कैशिंग को नियंत्रित करने के लिए, ट्रांसमिशन त्रुटियों का पता लगाने, उचित प्रतिनिधित्व प्रारूप पर बातचीत करने और प्रमाणीकरण या पहुंच नियंत्रण करने के लिए। और सबसे महत्वपूर्ण बात यह है कि एक संसाधन के साथ प्रत्येक बातचीत स्टेटलेस है।

Reactions

Post a Comment

0 Comments