REST और RESTful API को समझना

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

इस ट्यूटोरियल सीरीज में, हम REST सिद्धांतों और कॉन्सेप्ट्स के एक ओवरव्यू के साथ शुरू करेंगे। फिर हम अपने स्वयं के फुल-फ्लेज API बनाने के लिए आगे बढ़ेंगे जो एक node.js Express सर्वर पर चलता है और एक MySQL डेटाबेस से जुड़ता है। इस सीरीज को खत्म करने के बाद, आपको अपने स्वयं के API का निर्माण करने या मौजूदा API के डॉक्यूमेंटेशन में डेल्व होना चाहिए।

आवश्यक शर्तें

इस ट्यूटोरियल से अधिक लाभ प्राप्त करने के लिए, आपके पास पहले से ही कुछ बुनियादी कमांड लाइन ज्ञान होना चाहिए, JavaScript के मूलभूत सिद्धांतों को जानना चाहिए, और ग्लोबल स्तर पर इनस्टॉल Node.js होना चाहिए।

• टूल्स और टिप्स
  कमांड लाइन आपका सबसे अच्छा दोस्त है
  Patkos Csaba

REST और RESTful APIs क्या हैं?

रेप्रेसेंटेशनल स्टेट ट्रांसफर, या REST, वेब सर्विसेज के लिए एक आर्किटेक्चरल स्टाइल का वर्णन करता है। REST में विभिन्न प्रणालियों के बीच डेटा साझा करने के लिए स्टैंडर्ड्स या कन्सट्रैन्ट का एक सेट होता है, और REST को लागू करने वाले सिस्टम को RESTful के रूप में जाना जाता है। REST एक अब्स्ट्रक्ट (अमूर्त) अवधारणा है, न कि लैंग्वेज, फ्रेमवर्क, या सॉफ्टवेयर का टाइप।

REST के लिए एक ढीला सादृश्य (loose analogy) vinyl के संग्रह बनाम एक स्ट्रीमिंग म्यूजिक सर्विस का उपयोग करेगा। फिजिकल vinyl संग्रह के साथ, कॉपियों को शेयर और डिस्ट्रीब्यूट करने के लिए प्रत्येक रिकॉर्ड को पूरी तरह से डुप्लिकेट किया जाना चाहिए। एक स्ट्रीमिंग सर्विस के साथ, हालांकि, एक ही म्यूजिक को गाने के टाइटल जैसे कुछ डेटा के रिफरेन्स के माध्यम से अनंतकाल (perpetuity) में साझा किया जा सकता है। इस मामले में, स्ट्रीमिंग म्यूजिक एक RESTful सर्विस है, और vinyl संग्रह एक नॉन-RESTful सर्विस है।

एक API एक एप्लीकेशन प्रोग्रामिंग इंटरफेस है, जो एक इंटरफेस है जो सॉफ्टवेयर प्रोग्राम को एक दूसरे के साथ कम्यूनिकेट करने की अनुमति देता है। एक RESTful API केवल एक API है जो REST के सिद्धांतों और कन्सट्रैन्ट का पालन करता है। एक वेब API में, एक सर्वर को URL एंडपॉइंट के माध्यम से रिक्वेस्ट प्राप्त होता है और बदले में रिस्पांस भेजता है, जो प्रायः JSON जैसे फॉर्मेट में डेटा होता है।

REST के सिद्धांत

छह गाइडिंग कन्सट्रैन्ट नीचे उल्लिखित, REST आर्किटेक्चर को परिभाषित करती हैं।

1. Uniform Interface: कंपोनेंट्स का इंटरफ़ेस समान होना चाहिए। इसका मतलब रिसोर्सेज की पहचान करने के लिए URI स्टैण्डर्ड का उपयोग करना है- दूसरे शब्दों में, पाथ जो ब्राउज़र के लोकेशन बार में एंटर किए जा सकते हैं।
2. Client-Server: सर्वर के बीच कंसर्न का एक सेपरेशन है, जो डेटा को स्टोर करता है और उसका उपयोग करता है, और क्लाइंट, जो रिक्वेस्ट करता है और रिस्पांस को प्रदर्शित करता है।
3. Stateless Interactions: प्रत्येक रिक्वेस्ट के बारे में सभी जानकारी प्रत्येक व्यक्तिगत रिक्वेस्ट में निहित है और सेशन स्टेट पर निर्भर नहीं है।
4. Cacheable: क्लाइंट और सर्वर रिसोर्स कैश कर सकते हैं।
5. Layered System: क्लाइंट को अंतिम सर्वर से कनेक्ट किया जा सकता है, या एक इंटरमीडिएट लेयर जैसे लोड-बैलेंसर।
6. Code on Demand (वैकल्पिक): एक क्लाइंट कोड डाउनलोड कर सकता है, जो बाहर से विजिबिलिटी को कम करता है।

रिक्वेस्ट और रिस्पांस

आप पहले से ही इस तथ्य से परिचित होंगे कि सभी वेबसाइटों में ऐसे URL हैं जो http (या सिक्योर वर्जन के लिए https) से शुरू होते हैं। हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल, या HTTP, इंटरनेट पर क्लाइंट और सर्वर के बीच संचार का मेथड है।

हम इसे अपने ब्राउज़र के URL बार में सबसे स्पष्ट रूप से देखते हैं, लेकिन HTTP का उपयोग सर्वर से वेबसाइटों को रिक्वेस्ट करने के लिए किया जा सकता है। जब आप वेब पर किसी URL पर जाते हैं, तो आप वास्तव में उस विशिष्ट रिसोर्स पर एक GET रिक्वेस्ट कर रहे हैं, और जो वेबसाइट आप देखते हैं वह रिस्पांस का मुख्य भाग है। हम जल्द ही GET और अन्य प्रकार के रिक्वेस्ट्स पर जायेंगे।

एक रिक्वेस्ट करने के लिए एक सर्वर पोर्ट (http के लिए 80, https के लिए 443) के लिए एक TCP (ट्रांसमिशन कंट्रोल प्रोटोकॉल) कनेक्शन खोलकर HTTP काम करता है, और लिसनिंग सर्वर एक स्टेटस और बॉडी के साथ रिस्पांस देता है।

एक रिक्वेस्ट में एक URL, एक मेथड, हेडर जानकारी, और एक बॉडी होनी चाहिए।

रिक्वेस्ट मेथड

चार प्रमुख HTTP मेथड्स हैं, जिन्हें HTTP verbs भी कहा जाता है, जिनका उपयोग आमतौर पर वेब API के साथ इंटरैक्ट करने के लिए किया जाता है। ये मेथड्स उस एक्शन को परिभाषित करती हैं जो किसी दिए गए रिसोर्स के साथ किया जाएगा।

HTTP रिक्वेस्ट मेथड्स संक्षेप में CRUD के उदाहरण से मेल खाते हैं, जो कि Create, Update, Read, Delete के लिए स्टैंड करते हैं। हालांकि CRUD डेटाबेस संचालन में उपयोग किए जाने वाले फंक्शन्स को रेफेर करता है, लेकिन हम उन डिज़ाइन सिद्धांतों को एक विश्वसनीय API में HTTP verbs पर लागू कर सकते हैं।

GET एक सुरक्षित, केवल-पढ़ने वाला ऑपरेशन है जो सर्वर की स्थिति को नहीं बदलेगा। हर बार जब आप अपने ब्राउज़र में एक URL हिट करें, जैसे https://www.google.com, तो आप Google के सर्वर पर एक GET रिक्वेस्ट भेज रहे हैं।

एक नया रिसोर्स बनाने के लिए POST का उपयोग किया जाता है। POST का एक परिचित उदाहरण किसी वेबसाइट या ऐप पर यूजर के रूप में साइन अप करना है। फॉर्म सबमिट करने के बाद, यूजर डेटा के साथ एक POST रिक्वेस्ट सर्वर पर भेजा जा सकता है, जो तब उस जानकारी को डेटाबेस में लिख देगा।

PUT को मौजूदा रिसोर्स को अपडेट करता है, जिसका उपयोग किसी मौजूदा यूजर की सेटिंग्स को एडिट करने के लिए किया जा सकता है। POST के विपरीत, PUT idempotent है, जिसका अर्थ है कि एक ही परिणाम को बिना किसी परिणाम के कई बार बनाया जा सकता है। उदाहरण के लिए, यदि आपने डेटाबेस में कई बार एक नया यूजर बनाने के लिए एक ही POST रिक्वेस्ट भेजते है, तो यह आपके द्वारा किए गए प्रत्येक रिक्वेस्ट के लिए एक ही डेटा वाला एक नया यूजर बनाएगा। हालांकि, एक ही यूजर पर एक ही PUT रिक्वेस्ट का उपयोग लगातार एक ही परिणाम उत्पन्न करेगा।

DELETE, जैसा कि नाम से पता चलता है, बस एक मौजूदा रिसोर्स को डिलीट कर देगा।

रिस्पांस कोड

एक बार क्लाइंट से सर्वर पर रिक्वेस्ट करने के बाद, सर्वर एक HTTP रिस्पांस वापस भेज देगा, जिसमें हेडर के साथ-साथ बॉडी के रूप में जाने वाली रिस्पांस के बारे में मेटाडेटा शामिल होगा। रिस्पांस का पहला और सबसे महत्वपूर्ण हिस्सा status code है, जो इंगित करता है कि कोई एरर हुआ है, अगर कोई एरर हुआ है, या यदि कोई अन्य एक्शन लिया जाना चाहिए।

सबसे प्रसिद्ध रिस्पांस कोड 404 से आप परिचित होंगे, जिसका मतलब Not Found है। 404 स्टेटस कोड के 4xx क्लास का हिस्सा है, जो क्लाइंट एरर को इंगित करता है। स्टेटस कोड के पांच वर्ग हैं जिनमें प्रत्येक में कई प्रकार की रेस्पॉन्सेस होती हैं।

• 1xx: इनफार्मेशन
• 2xx: सक्सेस
  
• 3xx: रीडायरेक्शन
  
• 4xx: क्लाइंट एरर
  
• 5xx: सर्वर एरर

अन्य सामान्य रेस्पॉन्सेस जिनके बारे में आप परिचित हो सकते हैं, वे है 301 Moved Permanently, जिनका उपयोग वेबसाइटों को नए URL पर रीडायरेक्ट करते हैं, और 500 Internal Server Error, जो एक एरर है जो हमारे सामने आता रहता है जब कभी सर्वर पर कुछ अप्रत्याशी होता है जो कि इच्छित रिक्वेस्ट को फुलफिल होना असंभव बना देता है।

RESTful API और उनके संबंधित HTTP verbs के संबंध में, सभी रेस्पॉन्सेस 2xx रेंज में होने चाहिए।

200 OK रिस्पांस है जो इंगित करता है कि एक रिक्वेस्ट सफल है। इसे GET या PUT रिक्वेस्ट भेजते समय रिस्पांस के रूप में उपयोग किया जाता है। POST 201 Created को रीटर्न करेगा जो यह इंगित करने के लिए बनाया गया है कि एक नया रिसोर्स बनाया गया है, और DELETE के पास कुछ अक्सेप्टबले रेस्पॉन्सेस हैं, जो बताते हैं कि या तो रिक्वेस्ट को स्वीकार कर लिया गया है (202), या रीटर्न करने के लिए कोई कंटेंट नहीं है क्योंकि रिसोर्स मौजूद ही नहीं है (204)।

हम cURL का उपयोग कर रिसोर्स रिक्वेस्ट के स्टेटस कोड का परीक्षण कर सकते हैं, जो एक कमांड-लाइन टूल है जो URL के माध्यम से डेटा ट्रांसफर करने के लिए उपयोग किया जाता है। curl का उपयोग करके, और उसके बाद -i या --include फ्लैग लगाएं, यह एक URL में एक GET रिक्वेस्ट भेज देगा और हेडर और बॉडी प्रदर्शित करेगा। हम कमांड लाइन प्रोग्राम खोलकर और Google के साथ cURL परीक्षण करके इसका परीक्षण कर सकते हैं।

curl -i https://www.google.com

Google का सर्वर निम्नलिखित के साथ रेस्पॉन्ड देगा।

HTTP/2 200 
date: Tue, 14 Aug 2018 05:15:40 GMT 
expires: -1 
cache-control: private, max-age=0 
content-type: text/html; charset=ISO-8859-1 
...

जैसा कि हम देख सकते हैं, curl रिक्वेस्ट रिस्पांस के रूप में मल्टीप्ल हैंडर्स और पूरी HTML बॉडी देता है। चूंकि रिक्वेस्ट सफलतापूर्वक चला गया, रिस्पांस का पहला भाग 200 स्टेटस कोड है, HTTP के वर्जन के साथ (यह या तो HTTP/1.1 या HTTP/2 होगा)।

चूंकि यह विशेष रिक्वेस्ट वेबसाइट लौटा रहा है, इसलिए content-type (MIME टाइप) जो रीटर्न किया जा रहा है वो है text/html। एक विश्वसनीय API में, आप JSON रिस्पांस को इंगित करने के लिए application/json देखेंगे।

दिलचस्प बात यह है कि हम थोड़ा अलग URL इनपुट करके एक और प्रकार की रिस्पांस देख सकते हैं। www के बिना Google पर एक curl करें।

curl -i https://google.com

HTTP/2 301 
location: https://www.google.com/ 
content-type: text/html; 
charset=UTF-8

Google google.com को www.google.com पर रीडायरेक्ट करता है, और यह इंगित करने के लिए 301 रिस्पांस का उपयोग करता है कि रिसोर्स को रीडायरेक्ट किया जाना चाहिए।

REST API एंडपॉइंट्स

जब किसी API को सर्वर पर बनाया जाता है, तो इसमें मौजूद डेटा एंडपॉइंट्स के माध्यम से एक्सेसिबल होता है। endpoint रिक्वेस्ट का URL है जो GET, POST, PUT, या DELETE रिक्वेस्ट को स्वीकार और प्रोसेस कर सकता है।

एक API URL में रुट, पाथ और वैकल्पिक क्वेरी स्ट्रिंग शामिल होगी।

• Root e.g. https://api.example.com या https://api.example.com/v2: API का रुट, जिसमें प्रोटोकॉल, डोमेन और वर्जन शामिल हो सकता है।
• Path e.g. /users/ या /users/5: विशिष्ट रिसोर्स का स्पेसिफिक स्थान।
• Query Parameters (वैकल्पिक) e.g. ?location=chicago&age=29: ऑप्शनल key वैल्यू पेअर सॉर्टिंग, फ़िल्टरिंग और पेजिनेशन के लिए उपयोग किए जाते हैं।
  हम उन्हें नीचे दिए गए उदाहरण जैसे कुछ को लागू करने के लिए सभी को एक साथ रख सकते हैं, जो सभी यूज़र्स की एक लिस्ट रीटर्न कर देगा और रेस्पॉन्सेस को फ़िल्टर करने के लिए limit के क्वेरी पैरामीटर का उपयोग केवल दस परिणामों में शामिल करेगा।

https://api.example.com/users?limit=10

आम तौर पर, जब लोग एक API को एक विश्वसनीय API के रूप में रेफेर करते हैं, तो वे नेमिंग कन्वेंशन का जिक्र कर रहे हैं जो API URL एंडपॉइंट्स बनाने में लगते हैं। स्टैण्डर्ड RESTful API के लिए कुछ महत्वपूर्ण कन्वेंशन निम्नानुसार हैं:

• पाथ प्लुरल होना चाहिए: उदाहरण के लिए, यूजर को 5 की id के साथ प्राप्त करने के लिए, हम /users/5, नहीं /user/5 का उपयोग करेंगे।
• एंडपॉइंट्स को फ़ाइल एक्सटेंशन प्रदर्शित नहीं करना चाहिए: हालांकि एक API को JSON को रीटर्न करने की संभावना है, URL को .json में समाप्त नहीं होना चाहिए।
• एंडपॉइंट्स को nouns का उपयोग करना चाहिए, verbs का नहीं: add और delete जैसे शब्द एक REST URL में प्रकट नहीं होना चाहिए। एक नया यूजर जोड़ने के लिए, आप बस /users पर एक POST request को भेजेंगे, /users/add जैसा कुछ नहीं। API को एक ही URL में कई प्रकार के रिक्वेस्ट्स को संभालने के लिए डेवेलोप किया जाना चाहिए।
• पाथ केस सेंसिटिव होते हैं, और अंडरस्कोर के विपरीत हाइफ़न के साथ लोअरकेस में लिखा जाना चाहिए।

इन सभी कन्वेंशंस में गाइड लाइन हैं, क्योंकि फॉलो करने के लिए कोई सख्त REST स्टैंडर्ड्स नहीं हैं। हालांकि, इन गाइड लाइन्स का उपयोग करके आपके API को लगातार, परिचित और पढ़ने और समझने में आसान बना दिया जाएगा।

निष्कर्ष

इस आर्टिकल में, हमने सीखा है कि REST और RESTful API क्या हैं, HTTP रिक्वेस्ट मेथड्स और रिस्पांस कोड कैसे काम करते हैं, एक API URL के स्ट्रक्चर, और सामान्य RESTful API कन्वेंशन। अगले ट्यूटोरियल में, हम सीखेंगे कि इस थ्योरी को node.js के साथ एक Express सर्वर सेटअप करके और अपना स्वयं का API बनाकर कैसे उपयोग किया जाए।