CodeGym /Java Blog /अनियमित /बाकी का अवलोकन। भाग 2: क्लाइंट और सर्वर के बीच संचार
John Squirrels
स्तर 41
San Francisco

बाकी का अवलोकन। भाग 2: क्लाइंट और सर्वर के बीच संचार

अनियमित ग्रुप में प्रकाशित
बाकी का अवलोकन। भाग 1: बाकी क्या है? इस भाग में, हम इस बात पर गहराई से विचार करेंगे कि क्लाइंट और सर्वर के बीच संचार कैसे होता है। साथ ही, हम नई शर्तों को उजागर करेंगे और उन्हें समझाएंगे। बाकी का अवलोकन।  भाग 2: क्लाइंट और सर्वर के बीच संचार - 1यह सुनिश्चित करने के लिए कि सब कुछ स्पष्ट है, हम एक उदाहरण के रूप में RESTful एप्लिकेशन का उपयोग करके क्लाइंट-सर्वर संचार का विश्लेषण करेंगे। मान लीजिए कि हम एक वेब एप्लिकेशन विकसित कर रहे हैं जो ग्राहकों और उनके आदेशों के बारे में जानकारी संग्रहीत करता है। दूसरे शब्दों में, हमारा सिस्टम कुछ संस्थाओं पर संचालन करने में सक्षम है: उन्हें बनाएं, संपादित करें और हटाएं, और उनके बारे में जानकारी प्रदर्शित करें। ये संस्थाएं होंगी:
  • ग्राहक (ग्राहक)
  • आदेश (ग्राहक आदेश)
  • आइटम (उत्पाद)
एक रेस्टफुल आर्किटेक्चर में, क्लाइंट डेटा को पुनः प्राप्त करने या संशोधित करने के लिए सर्वर को अनुरोध भेजता है, और फिर सर्वर क्लाइंट को उनके अनुरोधों पर प्रतिक्रिया भेजता है।

अनुरोध

क्लाइंट अनुरोध लगभग हमेशा HTTP प्रोटोकॉल का उपयोग करके किए जाते हैं। सामान्य तौर पर, HTTP अनुरोधों में कई घटक होते हैं:
  • HTTP विधि
  • हैडर
  • यूआरआई
  • अनुरोध शरीर
नीचे हम प्रत्येक घटक पर अधिक विस्तार से विचार करेंगे।

यूआरआई और संसाधन

क्लाइंट द्वारा अनुरोधों के माध्यम से प्राप्त या संशोधित किए गए डेटा को संसाधन कहा जाता है। क्लाइंट-सर्वर संचार सभी संसाधनों में हेरफेर करने के बारे में है। REST में, संसाधन कुछ भी हैं जिन्हें आप एक नाम दे सकते हैं। एक मायने में, वे जावा में कक्षाओं की तरह हैं। जावा में हम किसी भी चीज के लिए एक क्लास बना सकते हैं। तो REST में, एक संसाधन कुछ भी हो सकता है: एक उपयोगकर्ता, एक दस्तावेज़, एक रिपोर्ट, एक आदेश। यह या तो किसी इकाई का सार हो सकता है, या कुछ विशिष्ट, उदाहरण के लिए, एक छवि, वीडियो, एनीमेशन या पीडीएफ फाइल। हमारे उदाहरण में, हमारे पास 3 संसाधन हैं:
  • ग्राहक (ग्राहक)
  • आदेश (ग्राहक आदेश)
  • आइटम (उत्पाद)
ग्राहक एंडपॉइंट्स के रूप में ज्ञात संसाधन स्थानों पर अनुरोध भेजते हैं। सीधे शब्दों में कहें, एक समापन बिंदु नेटवर्क पर एक पते की तरह होता है। गहराई में जाने पर, हम कह सकते हैं कि समापन बिंदु एक URI है, यानी वर्णों का एक क्रम जो एक सार या भौतिक संसाधन की पहचान करता है। यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) कभी-कभी एक समापन बिंदु या URI को पथ कहा जाता है, जिसका अर्थ है किसी संसाधन का पथ। इस लेख के प्रयोजनों के लिए, हम यूआरआई शब्द का प्रयोग करेंगे। प्रत्येक विशिष्ट संसाधन में एक अद्वितीय यूआरआई होना चाहिए। सर्वर डेवलपर यह सुनिश्चित करने के लिए ज़िम्मेदार है कि प्रत्येक संसाधन का अपना यूआरआई हमेशा होता है। हमारे उदाहरण में, हम डेवलपर हैं, इसलिए हम इसे वैसे ही करेंगे जैसे हम जानते हैं कि कैसे। जैसा कि आमतौर पर संख्यात्मक पहचानकर्ताओं को संबंधपरक डेटाबेस में प्राथमिक कुंजी के रूप में निर्दिष्ट करने के लिए प्रथागत होता है, REST में प्रत्येक संसाधन की अपनी आईडी भी होती है। REST में संसाधन ID अक्सर डेटाबेस में रिकॉर्ड की ID से मेल खाती है जो संसाधन के बारे में जानकारी संग्रहीत करती है। REST URI आमतौर पर किसी संसाधन का वर्णन करने वाली संज्ञा के बहुवचन रूप से शुरू होते हैं। उदाहरण के लिए, "
  • / ग्राहक - सभी उपलब्ध ग्राहकों का यूआरआई
  • /ग्राहक/23 — विशिष्ट ग्राहक का यूआरआई, यानी आईडी वाला ग्राहक=23
  • /ग्राहक/4 - एक विशिष्ट ग्राहक का यूआरआई, यानी आईडी वाला ग्राहक = 4।
लेकिन वह सब नहीं है। हम आदेश जोड़कर URI का विस्तार कर सकते हैं:
  • /ग्राहक/4/आदेश - ग्राहक संख्या 4 द्वारा किए गए सभी आदेशों का यूआरआई
  • /ग्राहक/1/आदेश/12 - ग्राहक संख्या 1 द्वारा किए गए आदेश संख्या 12 का यूआरआई।
यदि हम अधिक उत्पाद जोड़कर विस्तार जारी रखते हैं, तो हमें यह मिलता है:
  • /ग्राहक/1/आदेश/12/आइटम - ग्राहक संख्या 1 द्वारा बनाए गए क्रम संख्या 12 में सभी उत्पादों की सूची का यूआरआई।
जैसे ही हम नेस्टिंग के स्तर जोड़ते हैं, महत्वपूर्ण बात यह है कि URI को सहज बनाया जाए।

HTTP विधि

HTTP विधि किसी भी वर्ण का एक क्रम है (नियंत्रण वर्णों और परिसीमन को छोड़कर), जो संसाधन पर किए जा रहे मुख्य ऑपरेशन को इंगित करता है। कई सामान्य HTTP तरीके हैं। हम उन लोगों को सूचीबद्ध करेंगे जो अक्सर रेस्टफुल सेवाओं में उपयोग किए जाते हैं:
  • GET — किसी विशेष संसाधन (इसकी आईडी के माध्यम से) या संसाधनों के संग्रह के बारे में जानकारी प्राप्त करें
  • पोस्ट — एक नया संसाधन बनाएँ
  • PUT - एक संसाधन बदलें (इसकी आईडी के माध्यम से)
  • DELETE - एक संसाधन हटाएं (इसकी आईडी के माध्यम से)

हेडर

अनुरोधों के साथ-साथ प्रतिक्रियाओं में HTTP शीर्षलेख होते हैं। वे अनुरोध (या प्रतिक्रिया) के बारे में अतिरिक्त जानकारी देते हैं। हेडर की-वैल्यू पेयर होते हैं। आप विकिपीडिया पर सबसे सामान्य शीर्षकों की सूची देख सकते हैं । आरईएसटी के लिए, क्लाइंट अक्सर सर्वर से अनुरोधों में "स्वीकार करें" शीर्षलेख भेजते हैं। सर्वर को यह बताने के लिए इस शीर्षलेख की आवश्यकता है कि क्लाइंट किस प्रारूप में प्रतिक्रिया प्राप्त करने की अपेक्षा करता है। MIME प्रकारों की सूची में विभिन्न प्रारूप दिए गए हैं। MIME (बहुउद्देश्यीय इंटरनेट मेल एक्सटेंशन) जानकारी को एन्कोड करने और संदेशों को स्वरूपित करने के लिए एक विनिर्देश है ताकि उन्हें इंटरनेट पर भेजा जा सके। प्रत्येक MIME प्रकार में स्लैश द्वारा अलग किए गए दो भाग होते हैं - एक प्रकार और उपप्रकार। विभिन्न प्रकार की फ़ाइलों के लिए MIME प्रकारों के उदाहरण:
  • पाठ - पाठ / सादा, पाठ / सीएसएस, पाठ / html
  • इमेज - इमेज/पीएनजी, इमेज/जेपीईजी, इमेज/जीआईएफ
  • ऑडियो — ऑडियो/वेव, ऑडियो/एमपीईजी
  • वीडियो — वीडियो/mp4, वीडियो/ogg
  • एप्लिकेशन - एप्लिकेशन/जेसन, एप्लिकेशन/पीडीएफ, एप्लिकेशन/एक्सएमएल, एप्लिकेशन/ऑक्टेट-स्ट्रीम
उदाहरण के लिए, एक अनुरोध में इस तरह का हेडर हो सकता है:

Accept:application/json
यह शीर्षलेख सर्वर को बताता है कि क्लाइंट JSON प्रारूप में प्रतिक्रिया प्राप्त करने की अपेक्षा करता है।

अनुरोध शरीर

यह क्लाइंट द्वारा सर्वर को भेजा गया संदेश है। अनुरोध का कोई निकाय है या नहीं यह HTTP अनुरोध के प्रकार पर निर्भर करता है। उदाहरण के लिए, GET और DELETE अनुरोधों में आम तौर पर कोई अनुरोध निकाय नहीं होता है। लेकिन PUT और POST अनुरोध कर सकते हैं - यह केवल अनुरोध के उद्देश्य पर निर्भर करता है। आखिरकार, एक आईडी (जो URL में पारित किया गया है) का उपयोग करके डेटा प्राप्त करने और/या हटाने के लिए, आपको सर्वर पर अतिरिक्त डेटा भेजने की आवश्यकता नहीं है। लेकिन एक नया संसाधन (एक पोस्ट अनुरोध के माध्यम से) बनाने के लिए, आपको संसाधन भेजने की जरूरत है। मौजूदा संसाधन को संशोधित करने के लिए भी यही सच है। REST में, अनुरोध निकाय को अक्सर XML या JSON प्रारूप में भेजा जाता है। JSON प्रारूप सबसे आम है। मान लीजिए कि हम एक नया संसाधन बनाने के लिए सर्वर को एक अनुरोध भेजना चाहते हैं। यदि आप नहीं भूले हैं, हमने एक ऐसे एप्लिकेशन के उदाहरण पर विचार किया जो ग्राहक के आदेशों का प्रबंधन करता है। मान लीजिए हम एक नया ग्राहक बनाना चाहते हैं। हमारे मामले में, हम निम्नलिखित ग्राहक जानकारी संग्रहीत करते हैं: नाम, ईमेल, फोन नंबर। तब अनुरोध का मुख्य भाग निम्नलिखित JSON हो सकता है:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

अनुरोधों को एक साथ रखना

इसलिए, हमने जांच की है कि ग्राहक के अनुरोध में क्या हो सकता है। अब हम विवरणों के साथ अनुरोधों के कुछ उदाहरण देंगे
अनुरोध विवरण

GET /customers/23
Accept : application/json, application/xml
JSON या XML स्वरूप में ग्राहक संख्या 23 के बारे में जानकारी प्राप्त करें

POST /customers
{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}
निम्नलिखित क्षेत्रों के साथ एक नया ग्राहक बनाएँ:
नाम — अमीगो
ईमेल — amigo@jr.com
टेलीफोन नंबर — +1 (222) 333-4444

PUT /customers/1
{
  "name" : "Ben",
  "email" : "bigben@jr.com",
  "phone" : "+86 (868) 686-8686"
}
ग्राहक नंबर 1 को निम्नानुसार संपादित करें:
नाम - बेन
ईमेल - bigben@jr.com
टेलीफोन नंबर - +86 (868) 686-8686

DELETE /customers/12/orders/6
ग्राहक संख्या 12 द्वारा बनाए गए आदेश संख्या 6 को सिस्टम से हटा दें

जवाब

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

HTTP प्रतिक्रिया कोड

आइए HTTP प्रतिक्रिया कोड पर अधिक विस्तार से विचार करें। HTTP प्रोटोकॉल के माध्यम से किए गए अनुरोधों के लिए एक HTTP स्थिति कोड सर्वर प्रतिक्रिया की पहली पंक्ति का हिस्सा है। यह एक पूर्णांक है जिसमें तीन दशमलव अंक होते हैं। पहला अंक प्रतिक्रिया स्थिति कोड की श्रेणी को इंगित करता है। प्रतिक्रिया कोड आमतौर पर अंग्रेजी में एक व्याख्यात्मक वाक्यांश द्वारा पीछा किया जाता है, जो एक स्थान से अलग होता है। यह वाक्यांश प्रतिक्रिया के लिए मानव-पठनीय कारण है। उदाहरण:
  • 201 बनाया गया
  • अनधिकृत 401
  • 507 अपर्याप्त भंडारण
प्रतिक्रिया कोड क्लाइंट को अनुरोध का परिणाम बताता है और उसे यह निर्धारित करने की अनुमति देता है कि आगे क्या कार्रवाई की जाए। प्रतिक्रिया कोड कई वर्गों या समूहों में विभाजित हैं:
  • 1XX - सूचनात्मक
  • 2XX — ये कोड इंगित करते हैं कि क्लाइंट का अनुरोध सफलतापूर्वक प्राप्त और संसाधित किया गया था
  • 3XX - ये कोड ग्राहक को सूचित करते हैं कि ऑपरेशन को सफलतापूर्वक पूरा करने के लिए एक अतिरिक्त अनुरोध, आमतौर पर एक अलग यूआरआई के लिए किया जाना चाहिए।
  • 4XX - ग्राहक त्रुटि। ऐसे कोड गलत तरीके से लिखे गए अनुरोध के परिणामस्वरूप हो सकते हैं। एक अन्य उदाहरण सुप्रसिद्ध "404 नहीं मिला" कोड है, जो तब हो सकता है जब एक ग्राहक एक गैर-मौजूद संसाधन का अनुरोध करता है
  • 5XX - सर्वर त्रुटि। यदि सर्वर ऑपरेशन की विफलता के लिए ज़िम्मेदार है तो ये कोड क्लाइंट को वापस कर दिए जाते हैं
बाकी का अवलोकन। भाग 3: स्प्रिंग बूट पर एक विश्वसनीय सेवा का निर्माण
टिप्पणियां
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION