वेब सेवा एपीआई को व्यवस्थित करने के तरीके के बारे में थोड़ा सा

एक वेब सेवा को व्यवस्थित करने का एक कार्य था, जिसे एक ब्राउज़र और अन्य वेब सेवाओं से सामान्य ग्राहकों द्वारा एक्सेस किया जाएगा।

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

आप टिकट के लिए कीमतों को देख सकते हैं, प्री-बुक कर सकते हैं, आरक्षण भुना सकते हैं, खरीदे गए रिटर्न को हटा सकते हैं और आरक्षण हटा सकते हैं।

प्रश्न: एपीआई को व्यवस्थित करने का सबसे अच्छा तरीका क्या है?

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

एपीआई संगठन सिद्धांत

आर्किटेक्चर / विचारधारा विकल्पों द्वारा: REST , SOAP , XML-RPC और अन्य।

बहुत पढ़ने के बाद, मैंने REST चुना, क्योंकि यह उन स्थानों पर कम स्वतंत्रता देता है जहां इसकी आवश्यकता नहीं है: इस पद्धति का नाम और विधि का नाम। संक्षेप में: अब मेरे टिकट संसाधन हैं। टिकट के साथ प्रत्येक क्रिया HTTP पद्धति + URL के एक अद्वितीय संयोजन के माध्यम से उपलब्ध है। उदाहरण के लिए, प्री-बुकिंग (संक्षेप में, एक टिकट ऑर्डर बनाना): POST /orders.xml, एक टिकट ऑर्डर DELETE / सीमाओं/1.xml को हटाना और कीमतों को देखना GET /prices.xml।

हेबर पर और विकिपीडिया पर REST के बारे में और पढ़ें।

सबसे अच्छा खुला स्रोत REST और रूबी ऑन रेल्स एपीआई आर्टिकल, ActiveResource अध्याय रेल्स 3 इन नटशेल , ओ'रेली के सौजन्य से है। यह REST API क्लाइंट और सर्वर दोनों के दृष्टिकोण से स्थिति का वर्णन करता है। यह समझने के लिए पढ़ना बहुत उपयोगी है कि RESTful API का उपयोग करना क्यों आवश्यक है। इसके अलावा, यह रूबी ऑन रेल्स के साथ शामिल ActiveResource REST API क्लाइंट के एक बहुत ही दिलचस्प कार्यान्वयन का वर्णन करता है। ActiveResource कुछ अन्य भाषाओं में पोर्ट किया गया है और न केवल माणिकवादियों के लिए उपयोगी होगा।

ट्राइफल्स की कटौती के बाद पढ़े गए बाकी लेखों को ऊपर के एक हिस्से में निवेश किया जाता है।

कार्यान्वयन

कार्यान्वयन से, मुझे वास्तव में डिफ़ॉल्ट रूप से रेल द्वारा पेश की गई अवधारणा पसंद आई, और इसने DRY सिद्धांत का अपने सभी लोगों के साथ शोषण किया: उपयोगकर्ता प्रतिक्रियाओं (एचटीएमएल) को उत्पन्न करने के समान नियंत्रकों में एपीआई प्रतिक्रियाएं (एक्सएमएल, जेएसएन) उत्पन्न करना।

वैसे, DRY को लागू करने के लिए, एक उपयोगी कृत्यों_का_पापी प्लगइन है जो आपको XML टेम्प्लेट पर बहुत कुछ बचाने और रेल 3 फीचर पर एक नया रूबी बनाने की अनुमति देता है ।

इस विषय पर कई समझदार Stackoverflow धागे हैं, जैसे यह एक ।

एपीआई को एक स्टैंडअलोन मॉड्यूल के रूप में लागू करना

एपीआई के आयोजन के लिए कई डीएसएल हैं। उदाहरण के लिए, अंगूर, और अगर किसी को अंगूर और रूबी को पटरियों पर एकीकृत करने की आवश्यकता है, तो यहां: martinciu.com/2011/01/mounting-grape-api-inside-rails-application.html

प्रमाणीकरण

बहुत सारे प्रमाणीकरण / प्राधिकरण विकल्प हैं: मूल , टोकन का उपयोग करना, प्रमाण पत्र का उपयोग करना, Oauth ।

जहाँ तक मुझे ओहूत में पता चला है, हमारे मामले में यह फिट नहीं है, क्योंकि मेरे सर्वर पर कोई क्लाइंट खाता नहीं है जो एजेंट को लॉग इन करने की अनुमति दे सके। कोई अंतिम उपयोगकर्ता नहीं है, मुझे उसके बारे में पता नहीं है, इसलिए ओउथ के साथ विकल्प गायब हो जाता है।

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

सबसे बुनियादी विकल्प बुनियादी है (अनिवार्य रूप से एक उपयोगकर्ता नाम और पासवर्ड: उपयोगकर्ता : password@api.myserver.ru/orders.xml)।

मैंने स्टेटलेस टोकन के द्वारा प्रमाणीकरण का विकल्प चुना, क्योंकि यह उपयोगकर्ता को उपयोगकर्ता नाम और पासवर्ड के साथ ब्राउज़र में लॉग इन करने और ऑर्डर बनाने और उसी समय, एक स्वचालित वेब सेवा का उपयोग करके उसी उपयोगकर्ता (लेकिन टोकन के साथ) के साथ ऑर्डर बनाने की अनुमति देता है। मैं चाहता हूं कि मेरे प्रत्येक एजेंट के पास मेरे सर्वर पर ठीक एक उपयोगकर्ता हो।

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

इसके अलावा, मैंने एक स्टेटस टोकन विकल्प चुना, जो एक POST या GET पैरामीटर के रूप में पारित हुआ। HTTP हेडर में टोकन को बंद करने का एक और विकल्प है, और एक पैरामीटर द्वारा नहीं (यह एक अधिक REST संस्करण है, लेकिन इसे लागू करने के लिए थोड़ा अधिक कठिन है), जैसा कि अमेज़ॅन ने किया था । लेकिन यह मुझे लग रहा था कि इस मामले में, कार्यान्वयन का खेल मोमबत्ती के लायक नहीं है। इस विकल्प के लिए कोई विशेष लाभ नहीं है (ठीक है, शायद, अनुरोध संरचना को छोड़कर
थोड़ा और अधिक हो जाएगा), लेकिन एक परेशानी है।

एक वेब सेवा के प्राधिकरण \ प्रमाणीकरण के आयोजन पर संदर्भ:
stackoverflow.com/questions/6134082/restful-web-service-how-to-authenticate-requests-from-other-services
stackoverflow.com/questions/939836/service-based-authentication-using-tokens

कार्यान्वयन

रूबी ऑन रेल्स के लिए एक अद्भुत डेविस प्लगइन है, जिसके लिए टोकन द्वारा प्रमाणीकरण के लिए एक मॉड्यूल है। वस्तुतः, लाइनों के एक जोड़े - और आप कर रहे हैं।

युपीडी। सहकर्मी इस विषय पर माइनस करते हैं, आप कम से कम असहमत तो नहीं हैं। और फिर विषय का आधा मूल्य चर्चा में है, और आप चुप हैं!