REST चे विहंगावलोकन. भाग 2: क्लायंट आणि सर्व्हरमधील संप्रेषण

REST चे विहंगावलोकन. भाग १: आराम म्हणजे काय? या भागात, क्लायंट आणि सर्व्हर यांच्यात संवाद कसा होतो ते आम्ही खोलवर जाऊन पाहू. वाटेत, आम्ही नवीन अटी उघड करू आणि त्यांचे स्पष्टीकरण देऊ. सर्वकाही स्पष्ट आहे याची खात्री करण्यासाठी, आम्ही उदाहरण म्हणून RESTful अनुप्रयोग वापरून क्लायंट-सर्व्हर संप्रेषणाचे विश्लेषण करू. समजा आम्ही एक वेब ऍप्लिकेशन विकसित करत आहोत जे ग्राहक आणि त्यांच्या ऑर्डरबद्दल माहिती संग्रहित करते. दुसऱ्या शब्दांत, आमची प्रणाली विशिष्ट घटकांवर ऑपरेशन्स करण्यास सक्षम आहे: त्यांना तयार करा, संपादित करा आणि हटवा आणि त्यांच्याबद्दल माहिती प्रदर्शित करा. या संस्था असतील:

• ग्राहक (ग्राहक)
• ऑर्डर (ग्राहक ऑर्डर)
• वस्तू (उत्पादने)

रेस्टफुल आर्किटेक्चरमध्ये, क्लायंट सर्व्हरला डेटा पुनर्प्राप्त करण्यासाठी किंवा सुधारित करण्यासाठी विनंत्या पाठवतात आणि नंतर सर्व्हर क्लायंटला त्यांच्या विनंत्यांना प्रतिसाद पाठवतात.

विनंत्या

क्लायंट विनंत्या जवळजवळ नेहमीच HTTP प्रोटोकॉल वापरून केल्या जातात. सर्वसाधारणपणे, HTTP विनंत्यांमध्ये अनेक घटक असतात:

• HTTP पद्धत
• शीर्षलेख
• URI
• विनंती शरीर

खाली आम्ही प्रत्येक घटकाचा अधिक तपशीलवार विचार करू.

URI आणि संसाधने

क्लायंट विनंत्यांद्वारे प्राप्त किंवा सुधारित डेटाला संसाधने म्हणतात. क्लायंट-सर्व्हर संप्रेषण हे संसाधने हाताळण्याबद्दल आहे. REST मध्ये, संसाधने अशी कोणतीही गोष्ट आहे ज्याला तुम्ही नाव देऊ शकता. एका अर्थाने ते जावामधील वर्गांसारखे आहेत. Java मध्ये आपण कोणत्याही गोष्टीसाठी क्लास तयार करू शकतो. म्हणून REST मध्ये, संसाधन काहीही असू शकते: एक वापरकर्ता, एक दस्तऐवज, अहवाल, ऑर्डर. हे एकतर एखाद्या घटकाचे अमूर्त किंवा काहीतरी विशिष्ट असू शकते, उदाहरणार्थ, प्रतिमा, व्हिडिओ, अॅनिमेशन किंवा PDF फाइल. आमच्या उदाहरणात, आमच्याकडे 3 संसाधने आहेत:

• ग्राहक (ग्राहक)
• ऑर्डर (ग्राहक ऑर्डर)
• वस्तू (उत्पादने)

क्लायंट एंडपॉइंट्स म्हणून ओळखल्या जाणार्‍या संसाधन स्थानांवर विनंत्या पाठवतात. सोप्या भाषेत सांगायचे तर, एंडपॉईंट हा नेटवर्कवरील पत्त्यासारखा असतो. खोलवर जाऊन, आपण असे म्हणू शकतो की शेवटचा बिंदू म्हणजे URI, म्हणजे अमूर्त किंवा भौतिक संसाधन ओळखणारा वर्णांचा क्रम. युनिफॉर्म रिसोर्स आयडेंटिफायर (यूआरआय) कधीकधी एंडपॉईंट किंवा यूआरआयला पाथ म्हणतात, म्हणजे संसाधनाचा मार्ग. या लेखाच्या हेतूंसाठी, आम्ही URI ही संज्ञा वापरू. प्रत्येक विशिष्ट संसाधनाचा एक अद्वितीय URI असणे आवश्यक आहे. सर्व्हर डेव्हलपर हे सुनिश्चित करण्यासाठी जबाबदार आहे की प्रत्येक संसाधनाचा नेहमीच स्वतःचा URI असतो. आमच्या उदाहरणात, आम्ही डेव्हलपर आहोत, म्हणून आम्ही ते आम्हाला कसे माहीत आहे ते करू. रिलेशनल डेटाबेसमध्ये प्राथमिक की म्हणून संख्यात्मक अभिज्ञापक नियुक्त करण्याची प्रथा आहे त्याप्रमाणे, प्रत्येक संसाधनाचा REST मध्ये स्वतःचा ID देखील असतो. REST मधील संसाधन आयडी अनेकदा डेटाबेसमधील रेकॉर्डच्या आयडीशी जुळतो जो संसाधनाविषयी माहिती संचयित करतो. आरईएसटी यूआरआय काही संसाधनाचे वर्णन करणार्‍या संज्ञाच्या अनेकवचनी रूपाने सुरू होतात. उदाहरणार्थ, "

• /ग्राहक — सर्व उपलब्ध ग्राहकांचा URI
• /customers/23 — विशिष्ट ग्राहकाचा URI, म्हणजे ID=23 असलेला ग्राहक
• /customers/4 — विशिष्ट ग्राहकाचा URI, म्हणजे ID=4 असलेला ग्राहक.

पण एवढेच नाही. ऑर्डर जोडून आम्ही URI वाढवू शकतो:

• /customers/4/orders — ग्राहक क्रमांक 4 द्वारे केलेल्या सर्व ऑर्डरचा URI
• /customers/1/orders/12 — ग्राहक क्रमांक 1 द्वारे ऑर्डर क्रमांक 12 चा URI.

आम्ही आणखी उत्पादने जोडून विस्तार सुरू ठेवल्यास, आम्हाला मिळेल:

• /customers/1/orders/12/items — ग्राहक क्रमांक 1 द्वारे तयार केलेल्या क्रम क्रमांक 12 मधील सर्व उत्पादनांच्या सूचीचा URI.

जसे आपण नेस्टिंगचे स्तर जोडतो, महत्वाची गोष्ट म्हणजे URI अंतर्ज्ञानी बनवणे.

HTTP पद्धत

HTTP पद्धत ही कोणत्याही वर्णांचा क्रम आहे (नियंत्रण वर्ण आणि सीमांकक वगळता), जे संसाधनावर केले जाणारे मुख्य ऑपरेशन दर्शवते. अनेक सामान्य HTTP पद्धती आहेत. RESTful सेवांमध्ये बहुतेक वेळा वापरल्या जाणार्‍या आम्ही त्यांची यादी करू:

• GET — एखाद्या विशिष्ट संसाधनाबद्दल (त्याच्या आयडीद्वारे) किंवा संसाधनांच्या संग्रहाबद्दल माहिती मिळवा
• पोस्ट - एक नवीन संसाधन तयार करा
• पुट - संसाधन बदला (त्याच्या आयडीद्वारे)
• हटवा — संसाधन हटवा (त्याच्या आयडीद्वारे)

शीर्षलेख

विनंत्या, तसेच प्रतिसादांमध्ये HTTP शीर्षलेख असतात. ते विनंती (किंवा प्रतिसाद) बद्दल अतिरिक्त माहिती देतात. शीर्षलेख हे की-व्हॅल्यू जोड्या आहेत. तुम्ही विकिपीडियावर सर्वात सामान्य शीर्षलेखांची सूची पाहू शकता . REST साठी, क्लायंट बर्‍याचदा सर्व्हरला विनंती करताना "स्वीकारा" शीर्षलेख पाठवतात. क्लायंटला प्रतिसाद मिळण्याची अपेक्षा कोणत्या फॉरमॅटमध्ये आहे हे सर्व्हरला सांगण्यासाठी हे हेडर आवश्यक आहे. MIME प्रकारांच्या सूचीमध्ये विविध स्वरूप दिलेले आहेत. MIME (बहुउद्देशीय इंटरनेट मेल एक्स्टेंशन्स) हे माहिती एन्कोड करण्यासाठी आणि संदेशांचे स्वरूपन करण्यासाठी एक तपशील आहे जेणेकरून ते इंटरनेटवर पाठवले जाऊ शकतात. प्रत्येक MIME प्रकारात स्लॅशने विभक्त केलेले दोन भाग असतात - एक प्रकार आणि उपप्रकार. विविध प्रकारच्या फाइल्ससाठी MIME प्रकारांची उदाहरणे:

• मजकूर — मजकूर/साधा, मजकूर/सीएसएस, मजकूर/html
• प्रतिमा — image/png, image/jpeg, image/gif
• ऑडिओ — ऑडिओ/wav, ऑडिओ/mpeg
• व्हिडिओ — video/mp4, video/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 विनंत्यांना प्रतिसाद म्हणून परत केलेली माहिती JSON फॉरमॅटमध्ये देखील असू शकते. पण शेवटचा भाग जरा जास्तच मनोरंजक आहे.

HTTP प्रतिसाद कोड

चला HTTP प्रतिसाद कोडचा अधिक तपशीलवार विचार करूया. HTTP स्थिती कोड हा HTTP प्रोटोकॉलद्वारे केलेल्या विनंत्यांना सर्व्हर प्रतिसादाच्या पहिल्या ओळीचा भाग आहे. हा तीन दशांश अंकांचा समावेश असलेला पूर्णांक आहे. पहिला अंक प्रतिसाद स्थिती कोडचा वर्ग दर्शवतो. प्रतिसाद कोड सामान्यत: स्पेसद्वारे विभक्त केलेल्या इंग्रजीमध्ये स्पष्टीकरणात्मक वाक्यांशाद्वारे अनुसरला जातो. हा वाक्प्रचार प्रतिसादाचे मानवी वाचनीय कारण आहे. उदाहरणे:

• 201 तयार केले
• 401 अनधिकृत
• 507 अपुरा स्टोरेज

प्रतिसाद कोड क्लायंटला विनंतीचा परिणाम सांगतो आणि पुढे कोणती कृती करायची हे ठरवण्याची परवानगी देतो. प्रतिसाद कोड अनेक वर्ग किंवा गटांमध्ये विभागलेले आहेत:

• 1XX — माहितीपूर्ण
• 2XX — हे कोड सूचित करतात की क्लायंटची विनंती यशस्वीरित्या प्राप्त झाली आणि त्यावर प्रक्रिया केली गेली
• 3XX — हे कोड क्लायंटला सूचित करतात की ऑपरेशन यशस्वीरित्या पूर्ण करण्यासाठी अतिरिक्त विनंती, सामान्यतः वेगळ्या URI ला करणे आवश्यक आहे.
• 4XX — क्लायंट त्रुटी. असे कोड चुकीच्या पद्धतीने तयार केलेल्या विनंतीमुळे येऊ शकतात. दुसरे उदाहरण म्हणजे सुप्रसिद्ध "404 नॉट फाऊंड" कोड, जो जेव्हा क्लायंट अस्तित्वात नसलेल्या संसाधनाची विनंती करतो तेव्हा होऊ शकतो.
• 5XX - सर्व्हर त्रुटी. ऑपरेशनच्या अपयशासाठी सर्व्हर जबाबदार असल्यास हे कोड क्लायंटला परत केले जातात

REST चे विहंगावलोकन. भाग 3: स्प्रिंग बूटवर आरामदायी सेवा तयार करणे