एपीआय सर्व्हर म्हणजे काय? API मूलभूत

व्लादिमीर, नोव्हो येथील वेब डेव्हलपर म्हणतात:

वेबसाइट्स, वेब सेवा आणि मोबाइल ॲप्लिकेशन्सच्या बहुतेक विकासकांना लवकर किंवा नंतर क्लायंट-सर्व्हर आर्किटेक्चरला सामोरे जावे लागते, म्हणजे, वेब API विकसित करणे किंवा त्याच्याशी समाकलित करणे. प्रत्येक वेळी काहीतरी नवीन शोधू नये म्हणून, समान प्रणाली विकसित करण्याच्या अनुभवावर आधारित, वेब API डिझाइनसाठी तुलनेने सार्वत्रिक दृष्टीकोन विकसित करणे महत्वाचे आहे. या समस्येला वाहिलेल्या लेखांची एकत्रित मालिका आम्ही तुमच्या लक्षात आणून देत आहोत.

अंदाजे एक: वर्ण

एका क्षणी, दुसरी वेब सेवा तयार करण्याच्या प्रक्रियेत, मी क्लायंट ऍप्लिकेशन्सच्या गरजा पूर्ण करण्यासाठी वेब API डिझाइन करण्याच्या विषयावर माझे सर्व ज्ञान आणि विचार गोळा करण्याचे ठरवले आणि ते लेखाच्या स्वरूपात किंवा मालिकेच्या रूपात ठेवायचे. लेख अर्थात, माझा अनुभव निरपेक्ष नाही, आणि विधायक टीका आणि जोडण्या स्वागतार्ह आहेत.

वाचन तांत्रिकपेक्षा अधिक तात्विक असल्याचे दिसून आले, परंतु तांत्रिक भागाच्या चाहत्यांसाठी विचार करण्यासारखे काहीतरी असेल. मला शंका आहे की मी या लेखात मूलभूतपणे नवीन काहीतरी सांगेन, जे आपण कधीही ऐकले नाही, वाचले किंवा आपल्याबद्दल विचार केला नाही. फक्त सर्वकाही जुळवण्याचा प्रयत्न करत आहे युनिफाइड सिस्टम, सर्व प्रथम, आपल्या स्वत: च्या डोक्यात, आणि हे आधीच खूप मोलाचे आहे. तरीसुद्धा, माझ्या विचारांचा तुमच्या सरावात तुम्हाला उपयोग झाला तर मला आनंद होईल. तर चला.

क्लायंट आणि सर्व्हर

सर्व्हरया प्रकरणात, आम्ही नेटवर्कवर एक अमूर्त मशीन विचारात घेतो जी HTTP विनंती प्राप्त करण्यास, त्यावर प्रक्रिया करण्यास आणि योग्य प्रतिसाद परत करण्यास सक्षम आहे. या लेखाच्या संदर्भात, त्याचे भौतिक सार आणि अंतर्गत आर्किटेक्चर पूर्णपणे बिनमहत्त्वाचे आहेत, मग ते विद्यार्थी लॅपटॉप असो किंवा जगभरात विखुरलेले औद्योगिक सर्व्हरचे एक मोठे क्लस्टर असो. त्याच प्रकारे, हुडच्या खाली काय आहे, दारात विनंतीचे स्वागत कोणी केले, अपाचे किंवा Nginx, कोणते अज्ञात प्राणी, PHP, पायथन किंवा रुबी त्यावर प्रक्रिया करतात आणि प्रतिसाद निर्माण करतात, कोणता डेटा स्टोरेज वापरला जातो याने काही फरक पडत नाही. : Postgresql, MySQL किंवा MongoDB . मुख्य गोष्ट अशी आहे की सर्व्हर मुख्य नियम पूर्ण करतो - ऐकणे, समजून घेणे आणि क्षमा करणे.

क्लायंटहे HTTP विनंती व्युत्पन्न आणि पाठविण्यास सक्षम असलेले काहीही असू शकते. या लेखातील एका विशिष्ट मुद्द्यापर्यंत, आम्हाला ही विनंती पाठवताना क्लायंटने स्वत:साठी सेट केलेल्या उद्दिष्टांमध्ये देखील विशेष स्वारस्य असणार नाही किंवा तो प्रतिसादासह काय करेल. क्लायंट ब्राउझरमध्ये चालू असलेली JavaScript स्क्रिप्ट, मोबाइल ऍप्लिकेशन, सर्व्हरवर चालणारा दुष्ट (किंवा इतका वाईट नसलेला) राक्षस किंवा खूप शहाणा रेफ्रिजरेटर असू शकतो (असे आधीच आहेत).

बऱ्याच भागांमध्ये, आम्ही वरील दोघांमधील संवादाच्या पद्धतीबद्दल अशा प्रकारे बोलू की ते एकमेकांना समजून घेतील आणि दोघांपैकी कोणालाही प्रश्न नाही.

बाकीचे तत्वज्ञान

REST (प्रतिनिधित्वात्मक राज्य हस्तांतरण) मूलतः डेटा व्यवस्थापनासाठी एक साधा आणि अस्पष्ट इंटरफेस म्हणून कल्पित करण्यात आला होता, ज्यामध्ये थेट नेटवर्क स्टोरेज (सर्व्हर) सह फक्त काही मूलभूत ऑपरेशन्स समाविष्ट आहेत: डेटा पुनर्प्राप्ती (GET), बचत (POST), बदल (PUT/PATCH). ) आणि हटवणे (DELETE). अर्थात, या सूचीमध्ये नेहमी विनंतीमधील त्रुटी हाताळणे (विनंती योग्यरित्या संकलित केलेली आहे), डेटावर प्रवेश प्रतिबंधित करणे (अचानक तुम्हाला हे माहित नसावे) आणि येणारा डेटा सत्यापित करणे (अचानक तुम्ही मूर्खपणाने लिहिले आहे) अशा पर्यायांसह होते. सर्वसाधारण, सर्व संभाव्य तपासण्या, ज्याची सर्व्हर इच्छा पूर्ण करण्यापूर्वी कार्यान्वित करतो ग्राहक.

याव्यतिरिक्त, REST मध्ये अनेक वास्तुशास्त्रीय तत्त्वे आहेत, ज्यांची यादी REST बद्दलच्या इतर कोणत्याही लेखात आढळू शकते. चला त्यांच्याकडे थोडक्यात जाऊ या जेणेकरून ते जवळ असतील आणि तुम्हाला कुठेही जाण्याची गरज नाही:

क्लायंटपासून सर्व्हरचे स्वातंत्र्य- सर्व्हर आणि क्लायंट एकमेकांपासून स्वतंत्रपणे इतरांद्वारे त्वरित बदलले जाऊ शकतात, कारण त्यांच्यामधील इंटरफेस बदलत नाही. सर्व्हर क्लायंट स्थिती संचयित करत नाही.
संसाधन पत्त्यांची विशिष्टता- डेटाच्या प्रत्येक युनिटची (कोणत्याही प्रमाणात नेस्टिंगची) स्वतःची अनन्य URL असते, जी खरं तर संपूर्णपणे एक अद्वितीय संसाधन अभिज्ञापक आहे.

उदाहरण:/api/v1/users/25/name मिळवा

ट्रान्समिशन फॉरमॅटपासून डेटा स्टोरेज फॉरमॅटचे स्वातंत्र्य- समान डेटा (JSON, XML, इ.) प्रसारित करण्यासाठी सर्व्हर अनेक भिन्न स्वरूपनास समर्थन देऊ शकतो, परंतु डेटाला त्याच्या अंतर्गत स्वरूपामध्ये संचयित करतो, काहीही समर्थित असले तरीही.

प्रतिसादात सर्व आवश्यक मेटाडेटाची उपस्थिती- डेटा व्यतिरिक्त, सर्व्हरने विनंती प्रक्रियेचे तपशील परत करणे आवश्यक आहे, उदाहरणार्थ, त्रुटी संदेश, त्याच्यासह पुढील कार्य करण्यासाठी आवश्यक संसाधनाचे विविध गुणधर्म, उदाहरणार्थ, योग्य प्रदर्शनासाठी संग्रहातील एकूण रेकॉर्डची संख्या. पृष्ठ नेव्हिगेशनचे. आम्ही नंतर विविध प्रकारच्या संसाधनांवर जाऊ.

आपण काय गमावत आहोत?

क्लासिक REST मध्ये क्लायंट सर्व्हरसोबत फ्लॅट डेटा स्टोअर म्हणून काम करतो, तर कनेक्टिव्हिटी आणि डेटाच्या परस्परावलंबनाबद्दल काहीही सांगितले जात नाही. हे सर्व, डीफॉल्टनुसार, पूर्णपणे क्लायंट ऍप्लिकेशनच्या खांद्यावर येते. तथापि, आधुनिक विषय क्षेत्र ज्यासाठी डेटा व्यवस्थापन प्रणाली विकसित केल्या आहेत, ते असो समाज सेवाकिंवा इंटरनेट मार्केटिंग सिस्टीम, डेटाबेसमध्ये साठवलेल्या घटकांमधील एक जटिल संबंध सूचित करते. या कनेक्शनला समर्थन देणे, म्हणजे डेटा अखंडता ही सर्व्हरच्या बाजूची जबाबदारी आहे, तर क्लायंट हा डेटा ऍक्सेस करण्यासाठी फक्त एक इंटरफेस आहे. मग आपण REST मध्ये काय गमावत आहोत?

फंक्शन कॉल

डेटा आणि त्यांच्यामधील कनेक्शन व्यक्तिचलितपणे बदलू नये म्हणून, आम्ही फक्त संसाधनावरील फंक्शन कॉल करतो आणि युक्तिवाद म्हणून आवश्यक डेटा "फीड" करतो. हे ऑपरेशन REST मानकांमध्ये बसत नाही, त्यासाठी कोणतेही विशेष क्रियापद नाही, जे आम्हाला, विकसकांना आमच्या स्वतःच्या मार्गातून बाहेर पडण्यास भाग पाडते.

साधे उदाहरण- वापरकर्ता अधिकृतता. आम्ही लॉगिन फंक्शनला कॉल करतो, त्याला क्रेडेन्शियल्स असलेले ऑब्जेक्ट एक युक्तिवाद म्हणून पास करतो आणि प्रतिसादात ऍक्सेस की प्राप्त करतो. सर्व्हरच्या बाजूच्या डेटाचे काय होते हे आमच्यासाठी चिंतेचे नाही.

दुसरा पर्याय- डेटा दरम्यान कनेक्शन तयार करणे आणि तोडणे. उदाहरणार्थ, गटामध्ये वापरकर्ता जोडणे. घटकाला बोलावणे गट addUser फंक्शन, पॅरामीटर म्हणून ऑब्जेक्ट पास करणे वापरकर्ता, आम्हाला परिणाम मिळतो.

आणि देखीलअशी ऑपरेशन्स आहेत जी डेटा संचयित करण्याशी थेट संबंधित नाहीत, उदाहरणार्थ, सूचना पाठवणे, कोणत्याही ऑपरेशनची पुष्टी करणे किंवा नाकारणे (रिपोर्टिंग कालावधी पूर्ण करणे इ.).

एकाधिक ऑपरेशन्स

असे बऱ्याचदा घडते आणि क्लायंट डेव्हलपरला मला काय म्हणायचे आहे ते समजेल, की क्लायंट ऍप्लिकेशनसाठी एकाच विनंतीसह एकाच वेळी अनेक एकसंध वस्तू तयार करणे/बदलणे/हटवणे/हटवणे अधिक सोयीचे आहे आणि प्रत्येक ऑब्जेक्टसाठी भिन्न सर्व्हर-साइड निर्णय शक्य आहे. . येथे किमान अनेक पर्याय आहेत: एकतर सर्व बदल पूर्ण झाले आहेत, किंवा ते अंशतः पूर्ण झाले आहेत (काही वस्तूंसाठी), किंवा त्रुटी आली आहे. बरं, अनेक रणनीती देखील आहेत: प्रत्येकजण यशस्वी झाला तरच बदल लागू करा, किंवा अंशतः लागू करा, किंवा कोणतीही त्रुटी आढळल्यास मागे पडा आणि यामुळे आधीच पूर्ण व्यवहाराची यंत्रणा निर्माण होईल.

आदर्शासाठी प्रयत्न करणाऱ्या वेब API साठी, मला अशा प्रकारची ऑपरेशन्स सिस्टममध्ये आणण्याची इच्छा आहे. मी एका सिक्वेलमध्ये हे करण्याचा प्रयत्न करेन.

सांख्यिकीय क्वेरी, एकत्रित करणारे, डेटा स्वरूपन

असे बऱ्याचदा घडते की, सर्व्हरवर संचयित केलेल्या डेटाच्या आधारे, आम्हाला सांख्यिकीय सारांश किंवा डेटा विशेष प्रकारे स्वरूपित करणे आवश्यक आहे: उदाहरणार्थ, क्लायंटच्या बाजूने आलेख तयार करण्यासाठी. हा मूलत: मागणीनुसार, कमी-अधिक प्रमाणात तयार केलेला डेटा आहे आणि तो केवळ वाचनीय आहे, त्यामुळे त्याला वेगळ्या श्रेणीमध्ये ठेवणे अर्थपूर्ण आहे. पैकी एक वैशिष्ट्यपूर्ण प्रारूपमाझ्या मते सांख्यिकीय डेटा असा आहे की त्यांच्याकडे अद्वितीय आयडी नाही.

मला खात्री आहे की वास्तविक ऍप्लिकेशन्स विकसित करताना या सर्व गोष्टींचा सामना केला जाऊ शकत नाही आणि तुमची जोडणी आणि समायोजन पाहून मला आनंद होईल.

डेटाचे प्रकार

वस्तू

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

वस्तूंचा संग्रह

जेव्हा आम्ही संग्रहांबद्दल बोलतो, तेव्हा आमचा अर्थ एक प्रकारचा सर्व्हर संसाधन आहे जो तुम्हाला एकसंध वस्तूंच्या सूचीसह कार्य करण्यास अनुमती देतो, उदा. वस्तू जोडा, हटवा, बदला आणि त्यातून निवडा. याव्यतिरिक्त, संग्रहामध्ये सैद्धांतिकदृष्ट्या त्याचे स्वतःचे गुणधर्म असू शकतात (उदाहरणार्थ, प्रति पृष्ठ घटकांची कमाल संख्या) आणि कार्ये (मी येथे गोंधळलो आहे, परंतु हे देखील घडले).

स्केलर मूल्ये

त्यांच्या शुद्ध स्वरूपात, एक स्वतंत्र अस्तित्व म्हणून स्केलर मूल्ये माझ्या स्मृतीमध्ये अत्यंत दुर्मिळ आहेत. सामान्यत: ते वस्तू किंवा संग्रहाचे गुणधर्म म्हणून दिसले आहेत आणि जसे ते वाचले किंवा लिहिले जाऊ शकतात. उदाहरणार्थ, GET /users/1/name सह वापरकर्तानाव पुनर्प्राप्त आणि वैयक्तिकरित्या बदलले जाऊ शकते. सराव मध्ये, हे वैशिष्ट्य क्वचितच उपयुक्त आहे, परंतु आवश्यक असल्यास, मला ते हातात हवे आहे. हे विशेषतः संकलन गुणधर्मांसाठी खरे आहे, जसे की रेकॉर्डची संख्या (फिल्टरिंगसह किंवा त्याशिवाय): GET /news/count .

खालीलपैकी एका लेखात, मी या ऑपरेशन्सचे वर्गीकरण करण्याचा प्रयत्न करेन आणि संभाव्य विनंत्या आणि उत्तरांसाठी पर्याय ऑफर करेन, त्यापैकी कोणत्या मला सरावात आढळले आहेत.

अंदाजे दोन: योग्य मार्ग

या दृष्टिकोनामध्ये, मी तुमच्या वेब API च्या संसाधने आणि पद्धतींसाठी अद्वितीय मार्ग तयार करण्याच्या दृष्टिकोनांबद्दल आणि अनुप्रयोगाच्या त्या आर्किटेक्चरल वैशिष्ट्यांबद्दल स्वतंत्रपणे बोलू इच्छितो जे प्रभावित करतात देखावाहा मार्ग आणि त्याचे घटक.

किनाऱ्यावर उभे असताना काय विचार करावा

आवृत्ती तयार करणे

लवकरच किंवा नंतर, कोणतीही कार्यप्रणाली विकसित होण्यास सुरवात होते: विकसित करा, अधिक जटिल, स्केल आणि अधिक आधुनिक व्हा. REST API विकसकांसाठी, हे भरलेले आहे, सर्व प्रथम, जुन्या चालू असताना API च्या नवीन आवृत्त्या लॉन्च करण्याची आवश्यकता आहे. येथे मी यापुढे आपल्या सिस्टमच्या हुड अंतर्गत आर्किटेक्चरल बदलांबद्दल बोलत नाही, परंतु डेटा स्वरूप स्वतःच आणि त्यासह ऑपरेशन्सचा संच बदलत आहे याबद्दल बोलत आहे. कोणत्याही परिस्थितीत, मूळ संस्थेप्रमाणे आवृत्ती प्रदान करणे आवश्यक आहे मूळ सांकेतिक शब्दकोश, आणि तत्त्वतः URL चे बांधकाम. जेव्हा URL चा विचार केला जातो तेव्हा API ची आवृत्ती सूचित करण्याचे दोन सर्वात लोकप्रिय मार्ग आहेत ज्यावर विनंती केली जाते. उदाहरण-api.com/v1/ पथ प्रीफिक्स करणे आणि v1.example-api.com सबडोमेन स्तरावर आवृत्त्या विभक्त करणे. तुमच्या गरजा आणि गरजांनुसार तुम्ही त्यापैकी कोणतेही वापरू शकता.

घटकांची स्वायत्तता

एकाधिक वापरकर्त्यांच्या भूमिकांना समर्थन देणाऱ्या जटिल प्रणालींच्या वेब API ला बऱ्याचदा भागांमध्ये विभागणी आवश्यक असते, ज्यापैकी प्रत्येक कार्य त्याच्या स्वतःच्या श्रेणीसाठी करते. खरं तर, प्रत्येक भाग स्वतंत्र अनुप्रयोग असू शकतो, भिन्न भौतिक मशीन आणि प्लॅटफॉर्मवर चालतो. API चे वर्णन करण्याच्या संदर्भात, सर्व्हर विनंतीवर प्रक्रिया कशी करतो आणि यामध्ये कोणती शक्ती आणि तंत्रज्ञान सामील आहेत हे आमच्यासाठी अजिबात महत्त्वाचे नाही. क्लायंटसाठी, API एक एन्कॅप्स्युलेटेड सिस्टम आहे. तथापि, सिस्टमच्या वेगवेगळ्या भागांमध्ये पूर्णपणे भिन्न कार्यक्षमता असू शकते, उदाहरणार्थ, प्रशासकीय आणि वापरकर्ता भाग. आणि वरवर पाहता समान संसाधनांसह कार्य करण्याची पद्धत लक्षणीय भिन्न असू शकते. म्हणून, असे भाग admin.v1.example-api.com डोमेन किंवा example-api.com/v1/admin/ पथ उपसर्गाच्या स्तरावर वेगळे केले जाणे आवश्यक आहे. ही आवश्यकता अनिवार्य नाही आणि बरेच काही सिस्टमच्या जटिलतेवर आणि त्याच्या उद्देशावर अवलंबून असते.

डेटा एक्सचेंज फॉरमॅट

सर्वात सोयीस्कर आणि कार्यक्षम, माझ्या मते, डेटा एक्सचेंज फॉरमॅट JSON आहे, परंतु कोणीही XML, YAML किंवा इतर कोणत्याही स्वरूपाचा वापर करण्यास मनाई करत नाही जे आपल्याला डेटा प्रकार न गमावता अनुक्रमित वस्तू संचयित करण्यास अनुमती देते. इच्छित असल्यास, तुम्ही API ला एकाधिक इनपुट/आउटपुट स्वरूपनाचे समर्थन करू शकता. विनंतीमध्ये प्रसारित केलेल्या डेटाचे स्वरूप सूचित करण्यासाठी इच्छित स्वीकार प्रतिसाद स्वरूप आणि सामग्री-प्रकार सूचित करण्यासाठी HTTP विनंती शीर्षलेख वापरणे पुरेसे आहे. संसाधन URL मध्ये विस्तार जोडणे हा आणखी एक लोकप्रिय मार्ग आहे, उदाहरणार्थ, GET /users.xml, परंतु ही पद्धत कमी लवचिक आणि सुंदर दिसते, कारण ती URL अधिक जड बनवते आणि सर्व शक्यतेपेक्षा GET विनंत्यांसाठी सत्य आहे. ऑपरेशन्स

स्थानिकीकरण आणि बहुभाषिकता

व्यवहारात, API बहुभाषिकीकरण बहुतेकदा अंतिम वापरकर्त्यासाठी थेट प्रदर्शनासाठी आवश्यक भाषेत सेवा आणि त्रुटी संदेशांचे भाषांतर करण्यासाठी खाली येते. बहुभाषिक सामग्रीला देखील त्याचे स्थान आहे, परंतु माझ्या मते, वेगवेगळ्या भाषांमध्ये सामग्री जतन करणे आणि जारी करणे, अधिक स्पष्टपणे वेगळे केले पाहिजे, उदाहरणार्थ, जर तुमच्याकडे वेगवेगळ्या भाषांमध्ये समान लेख असेल, तर खरं तर या दोन भिन्न घटक आहेत, गटबद्ध सामग्रीच्या एकतेचे चिन्ह. अपेक्षित भाषा ओळखण्यासाठी तुम्ही वापरू शकता वेगळा मार्ग. सर्वात सोपा म्हणजे मानक HTTP शीर्षलेख Accept-Language. मी इतर मार्ग पाहिले आहेत, जसे की GET पॅरामीटर जोडणे language="en" , पथ उपसर्ग वापरणे example-api.com/en/ , किंवा डोमेन नाव स्तरावर en.example-api.com . मला असे दिसते की लोकॅल कसे निर्दिष्ट करायचे याची निवड यावर अवलंबून आहे विशिष्ट अनुप्रयोगआणि त्याच्यासमोरील कार्ये.

अंतर्गत राउटिंग

म्हणून आम्ही आमच्या API (किंवा त्यातील एक घटक) च्या रूट नोडवर पोहोचलो आहोत. पुढील सर्व मार्ग थेट तुमच्या सर्व्हर ऍप्लिकेशनमध्ये होतील, ते सपोर्ट करत असलेल्या संसाधनांच्या संचानुसार.

संकलनाचे मार्ग

संग्रहाचा मार्ग निर्दिष्ट करण्यासाठी, आम्ही फक्त संबंधित घटकाचे नाव वापरतो, उदाहरणार्थ, जर ही वापरकर्त्यांची सूची असेल, तर पथ /users असेल. संकलनासाठी दोन पद्धती लागू आहेत जसे की: GET (संस्थांची मर्यादित यादी प्राप्त करणे) आणि POST (नवीन घटक तयार करणे). सूचींच्या विनंत्यांमध्ये, आम्ही पेजिंग, क्रमवारी, फिल्टरिंग, शोध इत्यादीसाठी वापरलेले अनेक अतिरिक्त GET पॅरामीटर्स वापरू शकतो, परंतु ते पर्यायी असले पाहिजेत, उदा. हे पॅरामीटर्स मार्गाचा भाग म्हणून पास केले जाऊ नयेत!

संकलन घटक

विशिष्ट कलेक्शन घटकात प्रवेश करण्यासाठी, आम्ही रूटमध्ये त्याचा अद्वितीय ओळखकर्ता /users/25 वापरतो. हा त्याचा अनोखा मार्ग आहे. ऑब्जेक्टसह कार्य करण्यासाठी, GET (ऑब्जेक्ट मिळवणे), PUT/PATCH (बदलणे) आणि DELETE (हटवणे) या पद्धती लागू आहेत.

अद्वितीय वस्तू

बऱ्याच सेवांमध्ये वर्तमान वापरकर्त्यासाठी अद्वितीय असलेल्या वस्तू असतात, जसे की वर्तमान वापरकर्त्याचे प्रोफाइल /प्रोफाइल किंवा वैयक्तिक सेटिंग्ज /सेटिंग्ज. अर्थात, एकीकडे, हे संग्रहांपैकी एकाचे घटक आहेत, परंतु ते क्लायंट ऍप्लिकेशनद्वारे आमच्या वेब API च्या वापरासाठी प्रारंभिक बिंदू आहेत आणि डेटावरील ऑपरेशन्सच्या विस्तृत श्रेणीला देखील अनुमती देतात. त्याच वेळी, संग्रह संग्रहित सानुकूल सेटिंग्जसुरक्षा आणि डेटा गोपनीयतेच्या कारणांमुळे कदाचित उपलब्ध नसेल.

वस्तू आणि संग्रहांचे गुणधर्म

ऑब्जेक्टच्या कोणत्याही गुणधर्मांवर थेट जाण्यासाठी, ऑब्जेक्टच्या मार्गावर गुणधर्म नाव जोडणे पुरेसे आहे, उदाहरणार्थ, वापरकर्तानाव /users/25/name मिळवा. GET (मूल्य मिळवणे) आणि PUT/PATCH (मूल्य बदलणे) या पद्धती मालमत्तेला लागू आहेत. DELETE पद्धत लागू होत नाही कारण डेटाचे औपचारिक एकक म्हणून मालमत्ता हा ऑब्जेक्टचा एक संरचनात्मक भाग असतो.

मागील भागात, आपण वस्तूंप्रमाणेच संग्रहाचे स्वतःचे गुणधर्म कसे असू शकतात याबद्दल बोललो. माझ्या अनुभवात, मला उपयुक्त वाटलेली एकमेव मालमत्ता म्हणजे गणना गुणधर्म, परंतु तुमचा अर्ज अधिक जटिल आणि विशिष्ट असू शकतो. संग्रहांच्या गुणधर्मांचे मार्ग त्यांच्या घटकांच्या गुणधर्मांनुसार समान तत्त्वानुसार तयार केले जातात: /users/count . संकलन गुणधर्मांसाठी, फक्त GET (एक मालमत्ता मिळवणे) पद्धत लागू आहे, पासून संग्रह हा सूचीमध्ये प्रवेश करण्यासाठी फक्त एक इंटरफेस आहे.

संबंधित वस्तूंचा संग्रह

ऑब्जेक्ट प्रॉपर्टीचा एक प्रकार संबंधित वस्तू किंवा संबंधित वस्तूंचा संग्रह असू शकतो. अशा संस्था, एक नियम म्हणून, एखाद्या वस्तूची स्वतःची मालमत्ता नसतात, परंतु केवळ इतर घटकांसह त्याच्या कनेक्शनचा संदर्भ देतात. उदाहरणार्थ, वापरकर्त्याला नियुक्त केलेल्या भूमिकांची सूची /users/25/roles. आम्ही खालीलपैकी एका भागामध्ये नेस्टेड ऑब्जेक्ट्स आणि कलेक्शनसह काम करण्याबद्दल तपशीलवार बोलू, परंतु या टप्प्यावर आमच्यासाठी हे पुरेसे आहे की आमच्याकडे ऑब्जेक्टच्या इतर कोणत्याही मालमत्तेप्रमाणेच थेट प्रवेश करण्याची क्षमता आहे.

वस्तू आणि संग्रहांची कार्ये

कलेक्शन किंवा ऑब्जेक्टच्या फंक्शन कॉल इंटरफेसचा मार्ग तयार करण्यासाठी, आम्ही प्रॉपर्टी ऍक्सेस करण्यासाठी समान दृष्टीकोन वापरतो. उदाहरणार्थ, /users/25/sendPasswordReminder ऑब्जेक्ट किंवा /users/disableUnconfirmed संग्रहासाठी. फंक्शन कॉलसाठी, आम्ही नेहमी POST पद्धत वापरतो. का? मी तुम्हाला आठवण करून देतो की क्लासिक REST मध्ये कॉलिंग फंक्शन्ससाठी कोणतेही विशेष क्रियापद नाही आणि म्हणून आपल्याला विद्यमान क्रियापदांपैकी एक वापरावे लागेल. माझ्या मते, POST पद्धत यासाठी सर्वात योग्य आहे कारण... हे तुम्हाला सर्व्हरवर आवश्यक युक्तिवाद पास करण्यास अनुमती देते, अशक्त नाही (अनेक वेळा प्रवेश केल्यावर समान परिणाम परत करणे), आणि शब्दार्थात सर्वात अमूर्त आहे.

मला आशा आहे की सर्व काही कमी-अधिक प्रमाणात सिस्टममध्ये बसेल :) पुढील भागात आम्ही विनंत्या आणि प्रतिसाद, त्यांचे स्वरूप आणि स्थिती कोड याबद्दल अधिक तपशीलवार बोलू.

अंदाजे तीन: प्रश्न आणि उत्तरे

मागील अंदाजांमध्ये, मी वेब API डेव्हलपमेंटमधील विद्यमान अनुभव एकत्रित आणि सारांशित करण्यासाठी कल्पना कशी आली याबद्दल बोललो. पहिल्या भागात, वेब API डिझाइन करताना आम्ही कोणत्या प्रकारची संसाधने आणि ऑपरेशन्स हाताळतो याचे वर्णन करण्याचा प्रयत्न केला. दुसऱ्या भागात या संसाधनांमध्ये प्रवेश करण्यासाठी अद्वितीय URL तयार करण्याच्या मुद्द्यांना स्पर्श केला. आणि या अंदाजात मी वर्णन करण्याचा प्रयत्न करेन संभाव्य पर्यायविनंत्या आणि प्रतिसाद.

सार्वत्रिक उत्तर

आम्ही आधीच सांगितले आहे की सर्व्हर आणि क्लायंटमधील संप्रेषणाचे विशिष्ट स्वरूप विकासकाच्या विवेकबुद्धीनुसार कोणतेही असू शकते. माझ्यासाठी, JSON स्वरूप सर्वात सोयीस्कर आणि व्हिज्युअल आहे असे दिसते, जरी वास्तविक अनुप्रयोग अनेक स्वरूपनास समर्थन देऊ शकतो. आता प्रतिसाद ऑब्जेक्टची रचना आणि आवश्यक गुणधर्मांवर लक्ष केंद्रित करूया. होय, आम्ही सर्व्हरद्वारे परत केलेला सर्व डेटा एका विशेष कंटेनरमध्ये गुंडाळू - सामान्य प्रतिसाद ऑब्जेक्ट, ज्यामध्ये त्याच्या पुढील प्रक्रियेसाठी सर्व आवश्यक सेवा माहिती असेल. तर, ही माहिती काय आहे:

यश - विनंतीच्या यशाचे चिन्हक

विनंती यशस्वी झाली की नाही हे सर्व्हरकडून प्रतिसाद मिळाल्यावर लगेच समजण्यासाठी आणि योग्य हँडलरकडे पाठवण्यासाठी, "यश" यश टोकन वापरणे पुरेसे आहे. कोणताही डेटा नसलेला सर्वात सोपा सर्व्हर प्रतिसाद यासारखा दिसेल:

POST /api/v1/articles/22/publish ("यश": खरे)

त्रुटी - त्रुटी माहिती

विनंती अयशस्वी झाल्यास - आम्ही नकारात्मक सर्व्हर प्रतिसादांची कारणे आणि प्रकारांबद्दल थोड्या वेळाने बोलू - HTTP स्थिती कोड आणि त्रुटी संदेशाचा मजकूर असलेल्या प्रतिसादात "त्रुटी" विशेषता जोडली जाते. कृपया मेसेजमध्ये गोंधळ घालू नका प्रमाणीकरण त्रुटीविशिष्ट फील्डसाठी डेटा. माझ्या मते, प्रतिसाद शीर्षलेखात स्थिती कोड परत करणे हे सर्वात योग्य आहे, परंतु मी आणखी एक दृष्टीकोन देखील पाहिला आहे - हेडरमध्ये नेहमी स्थिती 200 (यश) परत करा आणि तपशील आणि संभाव्य त्रुटी डेटा पाठवा प्रतिसाद

GET /api/v1/user ("यश": असत्य, "त्रुटी": ("कोड": 401, "संदेश": "अधिकृतता अयशस्वी"))

डेटा - सर्व्हरद्वारे परत केलेला डेटा

बहुतेक सर्व्हर प्रतिसाद डेटा परत करण्यासाठी डिझाइन केलेले आहेत. विनंतीचा प्रकार आणि त्याचे यश यावर अवलंबून, अपेक्षित डेटा सेट बदलू शकतो, तथापि, "डेटा" विशेषता बहुसंख्य प्रतिसादांमध्ये उपस्थित असेल.

यशस्वी झाल्यास परत केलेल्या डेटाचे उदाहरण. या प्रकरणात, प्रतिसादात विनंती केलेला वापरकर्ता ऑब्जेक्ट असतो.

GET /api/v1/user ( "यशस्वी": सत्य, "डेटा": ( "id": 125, "ईमेल": " [ईमेल संरक्षित]", "नाव" : "जॉन", "आडनाव" : "स्मिथ", ) )

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

PUT /api/v1/user ( "यश": असत्य, "त्रुटी": ( "कोड" : 422, "संदेश" : "प्रमाणीकरण अयशस्वी") "डेटा": ( "ईमेल" : "ईमेल रिक्त असू शकत नाही. ", ))

पृष्ठांकन - पृष्ठ नेव्हिगेशन आयोजित करण्यासाठी आवश्यक माहिती

डेटा व्यतिरिक्त, प्रतिसाद परत येत आहे संकलन घटकांचा संच, क्वेरी परिणामांवर आधारित पृष्ठ नेव्हिगेशन (पृष्ठांकन) बद्दल माहिती उपस्थित असणे आवश्यक आहे.

पृष्ठांकनासाठी मूल्यांच्या किमान संचामध्ये हे समाविष्ट आहे:

• रेकॉर्डची एकूण संख्या;
• पृष्ठांची संख्या;
• वर्तमान पृष्ठ क्रमांक;
• प्रति पृष्ठ रेकॉर्डची संख्या;
• सर्व्हरच्या बाजूने समर्थित प्रति पृष्ठ रेकॉर्डची कमाल संख्या.

काही वेब एपीआय डेव्हलपर पृष्ठीकरणात लगतच्या पृष्ठांसाठी तयार लिंक्सचा संच तसेच प्रथम, शेवटचा आणि वर्तमान यांचाही समावेश करतात.

/api/v1/लेख प्रतिसाद मिळवा: ( "यश": सत्य, "डेटा": [ ( "आयडी" : 1, "शीर्षक" : "रंजक गोष्ट",), ( "आयडी" : 2, "शीर्षक" : "कंटाळवाणा मजकूर", ) ], "पृष्ठांकन": ( "एकूण रेकॉर्ड" : 2, "एकूणपृष्ठ" : 1, "वर्तमानपृष्ठ" : 1, "प्रतिपृष्ठ" : 20, "maxPerPage" : 100, ))

चुकांवर काम करा

वर नमूद केल्याप्रमाणे, वेब API च्या सर्व विनंत्या यशस्वी होत नाहीत, परंतु हा देखील गेमचा एक भाग आहे. एरर रिपोर्टिंग सिस्टम हे एक शक्तिशाली साधन आहे जे क्लायंटचे काम सोपे करते आणि क्लायंट ऍप्लिकेशनला योग्य मार्गावर मार्गदर्शन करते. या संदर्भात "त्रुटी" हा शब्द पूर्णपणे योग्य नाही. येथे एक चांगला शब्द असेल अपवाद, खरेतर विनंती यशस्वीरित्या प्राप्त झाली, पार्स केली गेली आणि विनंती पूर्ण का होऊ शकली नाही हे स्पष्ट करणारा पुरेसा प्रतिसाद परत आला.

तुम्हाला मिळालेल्या अपवादांची संभाव्य कारणे कोणती आहेत?

500 अंतर्गत सर्व्हर त्रुटी - सर्व काही तुटलेले आहे, परंतु आम्ही लवकरच त्याचे निराकरण करू

जेव्हा सर्व्हरच्या बाजूलाच समस्या उद्भवली तेव्हा हेच घडते आणि क्लायंट ऍप्लिकेशन फक्त उसासे टाकू शकतो आणि वापरकर्त्याला सूचित करू शकतो की सर्व्हर थकला आहे आणि विश्रांतीसाठी झोपला आहे. उदाहरणार्थ, डेटाबेसशी कनेक्शन गमावले आहे किंवा कोडमध्ये एक बग आहे.

400 वाईट विनंती - आणि आता सर्वकाही तुमच्यासाठी तुटलेले आहे

उत्तर मागील उत्तराच्या अगदी उलट आहे. ज्या प्रकरणांमध्ये क्लायंट ऍप्लिकेशनने विनंती पाठवली की, तत्त्वतः, योग्यरित्या प्रक्रिया केली जाऊ शकत नाही, आवश्यक पॅरामीटर्स नाहीत किंवा वाक्यरचना त्रुटी आहेत अशा प्रकरणांमध्ये परत आले. हे सहसा वेब API दस्तऐवजीकरण पुन्हा वाचून निराकरण केले जाऊ शकते.

401 अनधिकृत - अनोळखी, स्वत: ला ओळखा

या संसाधनात प्रवेश करण्यासाठी अधिकृतता आवश्यक आहे. अर्थात, अधिकृतता मिळाल्याने संसाधन उपलब्ध होईल याची हमी देत ​​नाही, परंतु अधिकृततेशिवाय, तुम्हाला निश्चितपणे कळणार नाही. उद्भवते, उदाहरणार्थ, API च्या खाजगी भागामध्ये प्रवेश करण्याचा प्रयत्न करताना किंवा वर्तमान टोकन कालबाह्य झाल्यावर.

403 निषिद्ध - तुम्हाला येथे परवानगी नाही

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

404 आढळले नाही - या पत्त्यावर कोणीही राहत नाही

असा प्रतिसाद, नियमानुसार, तीन प्रकरणांमध्ये परत केला जातो: संसाधनाचा मार्ग चुकीचा आहे (चुकीचा), विनंती केलेला स्त्रोत हटविला गेला आणि अस्तित्वात नाही, वर्तमान वापरकर्त्याचे अधिकार त्याला अस्तित्वाबद्दल जाणून घेण्याची परवानगी देत ​​नाहीत. विनंती केलेल्या संसाधनाचा. उदाहरणार्थ, आम्ही उत्पादनांची यादी पहात असताना, त्यापैकी एक अचानक फॅशनच्या बाहेर गेला आणि काढून टाकला गेला.

405 पद्धतीला परवानगी नाही - तुम्ही हे करू शकत नाही

या प्रकारचा अपवाद थेट विनंती (GET, PUT, POST, DELETE) मध्ये वापरल्या जाणाऱ्या क्रियापदाशी संबंधित आहे, जो यामधून, आम्ही संसाधनासह करण्याचा प्रयत्न करत असलेली क्रिया सूचित करतो. विनंती केलेले संसाधन निर्दिष्ट क्रियेस समर्थन देत नसल्यास, सर्व्हर स्पष्टपणे असे म्हणतो.

422 प्रक्रिया न करता येणारी संस्था - दुरुस्त करा आणि पुन्हा पाठवा

सर्वात उपयुक्त अपवादांपैकी एक. जेव्हा जेव्हा विनंती डेटामध्ये तार्किक त्रुटी असतील तेव्हा परत केले. विनंती डेटाद्वारे आमचा अर्थ एकतर पॅरामीटर्सचा संच आणि GET पद्धतीद्वारे उत्तीर्ण केलेली संबंधित मूल्ये किंवा POST, PUT आणि DELETE पद्धतींद्वारे विनंतीच्या मुख्य भागामध्ये पास केलेली ऑब्जेक्टची फील्ड. जर डेटा प्रमाणित केला गेला नसेल, तर सर्व्हर "डेटा" विभागात कोणते पॅरामीटर्स अवैध आहेत आणि का याबद्दल अहवाल देतो.

HTTP प्रोटोकॉल सर्व प्रसंगांसाठी मोठ्या संख्येने भिन्न स्टेटस कोडचे समर्थन करते, परंतु व्यवहारात ते क्वचितच वापरले जातात आणि वेब API च्या संदर्भात व्यावहारिक उपयोग होत नाही. माझ्या आठवणीत, मला वरील अपवादांच्या यादीच्या पलीकडे जावे लागले नाही.

विनंत्या

संग्रह आयटम पुनर्प्राप्त करत आहे

सर्वात सामान्य विनंत्यांपैकी एक म्हणजे संकलन घटक मिळविण्याची विनंती. क्लायंट ऍप्लिकेशन माहिती फीड, उत्पादन सूची, विविध माहिती आणि सांख्यिकीय तक्ते आणि बरेच काही संग्रह स्त्रोतांमध्ये प्रवेश करून प्रदर्शित करते. ही विनंती करण्यासाठी, आम्ही GET पद्धत वापरून आणि क्वेरी स्ट्रिंगमध्ये अतिरिक्त पॅरामीटर्स पास करून संग्रहात प्रवेश करतो. आम्ही आधीच वर सूचित केल्याप्रमाणे, प्रतिसाद म्हणून आम्हाला एकसंध संग्रह घटक आणि पृष्ठांकनासाठी आवश्यक माहिती - सूची किंवा तिचे विशिष्ट पृष्ठ लोड करणे अपेक्षित आहे. निवडीची सामग्री विशेषतः मर्यादित आणि हस्तांतरण वापरून क्रमवारी लावली जाऊ शकते अतिरिक्त पॅरामीटर्स. त्यांच्याशी पुढे चर्चा केली जाईल.

पृष्ठ नेव्हिगेशन

पृष्ठ- कोणते पृष्ठ प्रदर्शित केले जावे हे पॅरामीटर सूचित करते. जर हे पॅरामीटर पास केले नाही तर पहिले पृष्ठ प्रदर्शित केले जाईल. सर्व्हरच्या पहिल्या यशस्वी प्रतिसादावरून हे स्पष्ट होईल की सध्याच्या फिल्टरिंग पॅरामीटर्ससह संग्रहामध्ये किती पृष्ठे आहेत. जर मूल्य पृष्ठांच्या कमाल संख्येपेक्षा जास्त असेल, तर त्रुटी परत करणे चांगले 404 सापडले नाही .

/api/v1/news?page=1 मिळवा

प्रतिपृष्ठ- पृष्ठावरील घटकांची इच्छित संख्या दर्शवते. सामान्यतः, API चे स्वतःचे डीफॉल्ट मूल्य असते, जे पृष्ठांकन विभागात perPage फील्ड म्हणून परत केले जाते, परंतु काही प्रकरणांमध्ये ते तुम्हाला maxPerPage चे कमाल मूल्य प्रदान करून हे मूल्य वाजवी मर्यादेपर्यंत वाढवण्याची परवानगी देते:

/api/v1/news?perPage=100 मिळवा

वर्गीकरण परिणाम

बऱ्याचदा, तुम्हाला तुलनात्मक (संख्यात्मक फील्डसाठी) किंवा वर्णमाला (स्ट्रिंग फील्डसाठी) वर्गीकरणास समर्थन देणाऱ्या विशिष्ट फील्डच्या चढत्या किंवा उतरत्या मूल्यांद्वारे निवडीचे परिणाम क्रमवारी लावायचे आहेत. उदाहरणार्थ, आम्हाला वापरकर्त्यांची यादी नावानुसार किंवा किमतीनुसार उत्पादनांची व्यवस्था करायची आहे. याशिवाय, आम्ही क्रमवारीची दिशा A ते Z किंवा विरुद्ध दिशेने सेट करू शकतो आणि ती वेगवेगळ्या फील्डसाठी वेगळी आहे.

क्रमवारी लावा- GET पॅरामीटर्समध्ये जटिल क्रमवारी डेटा प्रसारित करण्यासाठी अनेक पद्धती आहेत. येथे क्रमवारी आणि दिशा स्पष्टपणे सूचित करणे आवश्यक आहे.

काही API हे स्ट्रिंग म्हणून करण्याचे सुचवतात:

/api/v1/products?sortBy=name.desc,price.asc मिळवा

इतर पर्याय ॲरे वापरण्याचा सल्ला देतात:

/api/v1/उत्पादने मिळवायची? sortBy=name& sortBy=desc& sortBy=price& sortBy=asc

सर्वसाधारणपणे, दोन्ही पर्याय समान आहेत, कारण ते समान सूचना देतात. माझ्या मते, ॲरेसह पर्याय अधिक सार्वत्रिक आहे, परंतु, जसे ते म्हणतात, ते चव आणि रंगावर अवलंबून असते ...

मूल्यानुसार साधे फिल्टरिंग

फील्डच्या मूल्यानुसार निवड फिल्टर करण्यासाठी, बहुतेक प्रकरणांमध्ये फील्डचे नाव आणि आवश्यक मूल्य फिल्टर पॅरामीटर म्हणून पास करणे पुरेसे आहे. उदाहरणार्थ, आम्हाला लेखक आयडीनुसार लेख फिल्टर करायचे आहेत:

/api/v1/articles?authorId=25 मिळवा

प्रगत फिल्टरिंग पर्याय

बऱ्याच इंटरफेसना अधिक जटिल फिल्टरिंग आणि शोध प्रणालीची आवश्यकता असते. मी मुख्य आणि सर्वात सामान्य फिल्टरिंग पर्यायांची यादी करेन.

(पेक्षा जास्त किंवा समान), उच्च (पेक्षा जास्त), ते (पेक्षा कमी किंवा समान), कमी (पेक्षा कमी) पासून तुलना ऑपरेटर वापरून वरच्या आणि खालच्या सीमांनुसार फिल्टर करणे. ज्या फील्डची मूल्ये रँक केली जाऊ शकतात त्यांना लागू होते.

/api/v1/products?price=500&price=1000 मिळवा

सूचीमधून अनेक संभाव्य मूल्यांनुसार फिल्टर करा. फील्डवर लागू होते ज्यांच्या संभाव्य मूल्यांचा संच मर्यादित आहे, उदाहरणार्थ, अनेक स्थितींद्वारे फिल्टर:

/api/v1/products?status=1&status=2 मिळवा

आंशिक स्ट्रिंग जुळणीनुसार फिल्टरिंग. मजकूर डेटा किंवा डेटा असलेल्या फील्डवर लागू होते जे मजकूराशी समतुल्य केले जाऊ शकते, जसे की संख्यात्मक उत्पादन SKU, फोन नंबर इ.

मिळवा /api/v1/users?name=John GET /api/v1/products?code=123

नावाचे फिल्टर

काही प्रकरणांमध्ये, जेव्हा फिल्टर पॅरामीटर्सचे ठराविक संच अनेकदा वापरले जातात आणि ते काहीतरी सर्वांगीण म्हणून सिस्टीमद्वारे निहित केले जातात, विशेषत: जर ते सॅम्पलिंगच्या अंतर्गत, अनेकदा जटिल यांत्रिकींवर परिणाम करतात, तेव्हा त्यांना तथाकथित नामांकित फिल्टरमध्ये गटबद्ध करण्याचा सल्ला दिला जातो. विनंतीमध्ये फिल्टरचे नाव पास करणे पुरेसे आहे आणि सिस्टम स्वयंचलितपणे निवड तयार करेल.

/api/v1/products?filters=recommended मिळवा

नामांकित फिल्टरचे स्वतःचे पॅरामीटर्स देखील असू शकतात.

/api/v1/products?filters=kidds मिळवा

या उपविभागात, मी आवश्यक नमुना मिळविण्यासाठी सर्वात लोकप्रिय पर्याय आणि पद्धतींबद्दल बोलण्याचा प्रयत्न केला. बहुधा, आपल्या सराव मध्ये या विषयाशी संबंधित आणखी बरीच उदाहरणे आणि बारकावे असतील. जर तुमच्याकडे माझ्या सामग्रीमध्ये जोडण्यासाठी काही असेल तर मला आनंद होईल. यादरम्यान, पोस्ट आधीच लक्षणीय प्रमाणात वाढली आहे, म्हणून आम्ही पुढील अंदाजात इतर प्रकारच्या विनंत्यांचे विश्लेषण करू.

6.1 परिमाण तपासा

मांडणी:

बुलियन परिमाण तपासा(परिमाण आयाम सूची,

आउट फ्लोट लांबी,

आउट फ्लोट रुंदी,

आउट फ्लोट उंची,

आउट फ्लोट वजन,

आउट स्ट्रिंग टिप्पणी)

पर्याय:

वर्णन:

पद्धत सर्व उत्पादनांच्या आयामी आणि वजन वैशिष्ट्यांची सूची प्राप्त करते
(DimensionsList). गणना केल्यानंतर, आउटपुट पॅरामीटर्स लांबी, रुंदी, उंची (लांबी,
अनुक्रमे रुंदी आणि उंची) सोडवल्यानंतर पार्सलच्या परिमाणांनी भरलेले आहेत
"इष्टतम बिछाना" चे कार्य, आणि वजन पॅरामीटरमध्ये सर्वांचे एकूण वजन समाविष्ट आहे
वस्तू, पॅकेजिंग साहित्य वगळून. इव्हेंटमध्ये की शिपमेंटची परिमाणे
मर्यादा मूल्ये ओलांडल्यास, मजकूराचे वर्णन टिप्पणी पॅरामीटरला दिले जाते
विसंगती

परतावा मूल्य:पद्धत बुलियन व्हॅल्यू True इफ मिळवते
मितीय आणि वजन वैशिष्ट्ये जास्तीत जास्त मूल्ये आणि वितरणापेक्षा जास्त नाहीत
कमीतकमी एका प्रवेशयोग्य मार्गाने शक्य आहे, अन्यथा असत्य. दिलेली असावी
ऑपरेशनल मूल्यांकनासाठी क्लायंटच्या बाजूने पद्धत वापरली जाऊ शकते
ऑर्डर पाठविण्याची मूलभूत शक्यता आणि वेळेवर स्वीकारण्याची शक्यता
हे शक्य नसल्यास उपाय.

6.1.1 CheckDimensions पद्धत कॉल करण्याचे उदाहरण

// चला असे गृहीत धरू की कार्टमध्ये 2 आयटम आहेत आणि ते ओलांडले की नाही हे तपासणे आवश्यक आहे
परवानगीयोग्य परिमाण आणि वजन यावर निर्बंध
aplix.Dimensions Dimensions = नवीन aplix.Dimensions;
aplix.DimensionsItem;

आयटम.लांबी = 0.130f;
आयटम.रुंदी = 0.100f;
आयटम.उंची = 0.001f;
आयटम.वजन = 0.1f;
आयटम.क्यूटी = 2;
परिमाण = आयटम;
आयटम = नवीन aplix.Dimensions();
आयटम.लांबी = 0.1331f;
आयटम.रुंदी = 0.0998f;
आयटम.उंची = 0.0788f;
आयटम.वजन = 0.575f;
आयटम.प्रमाण = 1;
परिमाण = आयटम;
// आउटपुट पॅरामीटर्स
फ्लोट लांबी;
फ्लोट रुंदी;
फ्लोट उंची;
फ्लोट वजन;
स्ट्रिंग टिप्पणी;
// परिमाणे आणि वजन वैशिष्ट्ये तपासा
bool परिणाम = ws.CheckDimenshions(परिमाण, लांबी बाहेर, रुंदी जास्त, उंची जास्त, वजन जास्त, टिप्पणी बाहेर);
// परिणामाची कल्पना करा
प्रतिसाद लिहा("परिणाम: " + Result.ToString() + "");
प्रतिसाद लिहा("लांबी: " + लांबी. ToString() + "");
प्रतिसाद लिहा("रुंदी: " + Width.ToString() + "");
प्रतिसाद लिहा("उंची: " + उंची. ToString() + "");
प्रतिसाद लिहा("वजन: " + Weight.ToString() + "");
प्रतिसाद लिहा("वजन: " + टिप्पणी + "");

6.2 ShippingCost पद्धतीची गणना करा

मांडणी:
लांब शिपिंग खर्चाची गणना करा(स्ट्रिंग ऑर्डर क्रमांक,
फ्लोट घोषित खर्च,
वस्तू वस्तू,
पत्ता पत्ता,
बाइट प्रकारऑफसील,
बुलियन स्टर्डी पॅकेजिंग,
बुलियन कॅशऑन डिलिव्हरी,
वितरणाचे प्रकार,
आउट स्ट्रिंग टिप्पण्या) पॅरामीटर्स:

वर्णन:

पद्धत, निर्दिष्ट पॅरामीटर्सवर आधारित, उपलब्ध वितरण पर्यायांची सूची प्रदर्शित करते
(टाईप आउटपुट पॅरामीटर) स्ट्रक्चर्सची ॲरे म्हणून<Идентификатор способа доставки, Наименование способа доставки, Себестоимость доставки, Страховую премию, Затраты на упаковку и маркировку, Адрес нахождения почтового отделения, либо точки самовывоза, Режим работы почтового отделения, либо точки самовывоза, Минимальное количество дней доставки, Максимальное количество дней доставки, Доп.информация>. गणना प्रक्रियेदरम्यान काही अपवाद आढळल्यास, नंतर
त्रुटीचे वर्णन टिप्पण्या पॅरामीटरमध्ये परत केले जाईल.

परतावा मूल्य:

पद्धत एक अद्वितीय गणना अभिज्ञापक परत करते, जो भविष्यात वापरला जाईल
पद्धत वापरून साहित्य आणि मजुरीच्या खर्चाच्या तपशीलांची विनंती करणे शक्य होईल
डिटेल्सऑफकॉस्ट मिळवा.

6.2.1 CalculateShippingCost पद्धतीला कॉल करण्याचे उदाहरण

ws.Credentials = नवीन NetworkCredential("test", "test");


Address.Index = "684005";


Address.City = "एलिझोवो शहर";

Address.Home = "16";


aplix.GoodsItem;
आयटम = नवीन aplix.Goods();
आयटम.SKU = "216293";

आयटम.लांबी = 0.130f;
आयटम.रुंदी = 0.100f;
आयटम.उंची = 0.001f;
आयटम.वजन = 0.1f;
आयटम.क्यूटी = 2;
वस्तू = वस्तू;
आयटम = नवीन aplix.Goods();
आयटम.SKU = "499687";

आयटम.लांबी = 0.1331f;
आयटम.रुंदी = 0.0998f;
आयटम.उंची = 0.0788f;
आयटम.वजन = 0.575f;
आयटम.प्रमाण = 1;
वस्तू = वस्तू;
// कॅल्क्युलेटरसाठी पॅरामीटर्स भरा
string OrderNumber="1234567890";
float DeclaredCost = 36370;
sbyte TypeOfSeal = 1;
bool SturdyPackaging = खरे;
bool CashOnDelivery = खोटे;
aplix.DeliveryTypeTypes; स्ट्रिंग टिप्पण्या;
// कॅल्क्युलेटरला कॉल करा
long Status = ws.CalculateShippingCost(OrderNumber, Declared Cost, Goods, Address,TypeOfSeal, SturdyPackaging,CashOnDelivery, out Types, out comments);
// परिणामाचे व्हिज्युअलायझेशन
प्रतिसाद लिहा("गणना आयडी: "+Status.ToString()+"
");
प्रतिसाद लिहा("अतिरिक्त गणना माहिती: " + टिप्पण्या + "
");
प्रतिसाद.लिहा(@"
");
foreach (प्रकारांमध्ये aplix. DeliveryType प्रकार) (
प्रतिसाद लिहा(""+ "" + "" + "" + "" + "" "" + "" + "" + "" + "" + "" + "" + "); )
प्रतिसाद.लिहा("

");

 } 


6.3 पुशऑर्डर पद्धत
मांडणी: 
     लांब पुशऑर्डर(
           आयडी, 
           क्रमांक, 
           तारीख 
           ग्राहक, 
           घोषित खर्च 
           ToBePaid रक्कम, 
           वितरण प्रकार आयडी, 
           TypeOfSeal, 
           मजबूत पॅकेजिंग, 
           क्रियाकलाप 
           वस्तू, 
           वितरण तारीख 
           स्टार्टटाइम डिलिव्हरी, 
           EndTime Delivery 
           टिप्पणी, 
           ShipperId, 
           मार्कर) 
पर्याय:
पॅरामीटर नाव
इनपुट/आउटपुट
प्रकार
वर्णन
आयडी
इनपुट
स्ट्रिंग
सिस्टममध्ये ऑर्डर आयडी 
ग्राहक (अद्वितीय मूल्य)
क्रमांक
इनपुट
स्ट्रिंग
ग्राहकांच्या सिस्टममधील ऑर्डर क्रमांक 
(टिप्पण्यांमध्ये छापले जाईल 
शिपमेंट चिन्हांकित करताना)
तारीख
इनपुट
तारीख वेळ
ग्राहकांच्या सिस्टममधील ऑर्डरची तारीख (असेल 
टिप्पण्या मध्ये मुद्रित तेव्हा 
शिपमेंटचे लेबलिंग
ग्राहक
इनपुट
ग्राहक
खरेदीदार माहिती, रचना 

घोषित खर्च
इनपुट
तरंगणे
वस्तूचे घोषित मूल्य.  चालू 
निर्दिष्ट रक्कम जारी केली जाईल 
विमा
रक्कम ToBeP 
मदत
इनपुट
तरंगणे
बेरीज 
ला 
पेमेंट 
तर 
ऑर्डर 
मी 0 प्रीपे करेन.
DeliveryTypeId
इनपुट
इंट
निवडलेल्या पद्धतीचा आयडी 
वितरण
TypeOfSeal
इनपुट
इंट
पर्याय 
सील 
शक्य 
मूल्ये: 
1 आवश्यक नाही 
2 बबल रॅप 
3 फिलर
मजबूत पॅकेजिंग
इनपुट
बुलियन
कडक आहे 
पॅकेज
क्रियाकलाप
इनपुट
बुलियन
ऑर्डरची प्रासंगिकता.  खरे - ऑर्डर असल्यास 
संबंधित, असत्य – ऑर्डर रद्द केल्यास.
माल
इनपुट
माल
उत्पादनांची यादी
वितरण तारीख
इनपुट
तारीख वेळ
वितरण तारीख, निवडल्यास भरा 
त्वरित वितरण
StartTimeDeliv 
ery
इनपुट
इंट
इच्छूक 
वेळ 
वितरण 
"सोबत", 

वितरण
EndTime Delivery
इनपुट
इंट
इच्छित वितरण वेळ "पूर्वी" 
कुरिअर निवडल्यास भरावे 
वितरण
टिप्पणी
इनपुट
स्ट्रिंग
ऑर्डरवर टिप्पण्या
ShipperId
इनपुट
स्ट्रिंग
ओळखकर्ता 
पाठवणारा, 
भरले आहे 
तर 
प्रतिपक्ष येथे 
अनेक ऑनलाइन स्टोअर्स
मार्कर
इनपुट
स्ट्रिंग
ऑर्डर मार्कर, भरले असल्यास 
शिपमेंट टॅगसह चिन्हांकित आहेत 
संकेतस्थळ
वर्णन:
पद्धत कंत्राटदाराच्या प्रणालीमध्ये ऑर्डरबद्दल माहिती देते.  सिस्टम ग्राहक 
ऑर्डर क्रमांक आणि तारीख, युनिक ऑर्डर आयडेंटिफायर, याबद्दल माहिती प्रसारित करते 
प्राप्तकर्ता, त्याचा पत्ता आणि दूरध्वनी क्रमांकासह, घोषित मूल्य, वितरणावर रोख रक्कम 
पेमेंट, जर असेल तर, कमोडिटी गुंतवणुकीची रचना, पॅकेजिंगचा प्रकार आणि निवडलेले 
वितरण पद्धत आणि तपशील.
परतावा मूल्य:
पद्धत कंत्राटदाराच्या प्रणालीमध्ये एक अद्वितीय ऑर्डर आयडेंटिफायर परत करते.
6.3.1 पुशऑर्डर पद्धत कॉल करण्याचे उदाहरण

aplix.Delivery ws = नवीन aplix.Delivery(); 
ws.Credentials = नवीन NetworkCredential("test", "test"); 
// "शिपमेंटचा प्राप्तकर्ता" रचना तयार करा 
aplix.Customer Customer = नवीन aplix.Customer(); 
// 684005, कामचटका प्रदेश, एलिझोव्स्की जिल्हा, एलिझोवो शहर, लेनिन्स्काया स्ट्रीट, इमारत क्रमांक 16 
aplix.Address Address = नवीन aplix.Address(); 
Address.Index = "684005"; 
Address.Region = "कामचटका प्रदेश"; 
Address.District = "येलिझोव्स्की जिल्हा"; 
Address.City = "एलिझोवो शहर"; 
Address.Street = "Leninskaya Street"; 
Address.Home = "16"; 
ग्राहक.पत्ता = पत्ता; 
Customer.ID = " [ईमेल संरक्षित]";
Customer.Name = "Sergey"; 
ग्राहक.ईमेल = " [ईमेल संरक्षित]";
ग्राहक.फोन = "+7(916)975-53-54"; 
// ऑर्डर पॅरामीटर्स भरा 
string ID = "2013-1234567890";  // क्लायंटच्या सिस्टममध्ये अद्वितीय ऑर्डर आयडेंटिफायर 
स्ट्रिंग क्रमांक = "1234567890";  // क्लायंटच्या सिस्टममध्ये ऑर्डर क्रमांक 
DateTime Date = नवीन DateTime(2013, 08, 30); 
float DeclaredCost = 36350.0f;  // घोषित मूल्य 
फ्लोट AmountToBePaid = 0;  // वितरणावर रोख नाही 
int DeliveryTypeId = 4;  // EMC 
sbyte TypeOfSeal = 2;  // बबल रॅप 
bool SturdyPackaging = खरे;  // कठोर पॅकेजिंग (नाजूक वस्तूंसाठी) 
bool क्रियाकलाप = खरे;  // दस्तऐवज चालू आहे 
// असे गृहीत धरू की ऑर्डरमध्ये 2 आयटम आहेत 
aplix.Goods Goods = नवीन aplix.Goods; 
aplix.GoodsItem; 
आयटम = नवीन aplix.Goods(); 
आयटम.SKU = "216293"; 
Item.Name = "SDXC 64Gb वर्ग 10 ट्रान्ससेंड मेमरी कार्ड"; 
आयटम.लांबी = 0.130f; 
आयटम.रुंदी = 0.100f; 
आयटम.उंची = 0.001f; 
आयटम.वजन = 0.1f; 
आयटम.प्रमाण = 1; 
आयटम.किंमत = 2080.0f; 
Item.VATRate = "VAT18"; 
वस्तू = वस्तू; 
आयटम = नवीन aplix.Goods(); 
आयटम.SKU = "499687"; 
आयटम.नाव = "मिरर" कॅनन कॅमेरा EOS 650D किट Tamron AF 18-270mm काळा"; 
आयटम.लांबी = 0.1331f; 
आयटम.रुंदी = 0.0998f; 
आयटम.उंची = 0.0788f; 
आयटम.वजन = 0.575f; 
आयटम.प्रमाण = 1; 
आयटम.किंमत = 34270.0f; 
Item.VATRate = "VAT18"; 
वस्तू = वस्तू; 
तारीख वेळ वितरण तारीख = नवीन तारीख वेळ(2013, 09, 05);  // ०९/०५/२०१३ रोजी वितरण 
int StartTimeDelivery = 10;  // वितरण मध्यांतर 10 पासून 
int EndTimeDelivery = 14;  // 14 पर्यंत 
string Comment = "चाचणी क्रम"; 
// ऑर्डर सिस्टममध्ये खेचा 
long OrderId = ws.PushOrder(ID, Number, Date, Customer, Declared Cost, AmountToBePaid, DeliveryTypeId, TypeOfSeal, SturdyPackaging, Activity, Goods, Delivery Date, StarttimeDelivery, EndTime Delivery, "," Comment, ""); 
प्रतिसाद लिहा("ऑर्डर आयडी: " + OrderId.ToString() + "

");


6.4 GetDetailsOfCost पद्धत
वाक्यरचना:        DetailsOfCostList GetDetailsOfCost (ID, TypeId) पॅरामीटर्स:
इनपुट/आउटपुट 
प्रकार 
वर्णन
इनपुट 
लांब 
CalculateShippingCost पद्धतीला कॉल करताना कॅल्क्युलेशन आयडी (युनिक व्हॅल्यू) मिळवला
इनपुट 
इंट 

पॅरामीटर नाव
आयडी
TypeId
वर्णन: पद्धत निर्दिष्ट गणना अभिज्ञापक आणि वितरण पर्याय अभिज्ञापकावर आधारित शिपमेंट चिन्हांकित आणि पॅकेजिंगसाठी खर्चांची तपशीलवार यादी देते. परतावा मूल्य:पद्धत स्ट्रक्चर्सची ॲरे देते 


ॲरेच्या प्रत्येक घटकामध्ये किंमत, प्रमाण, किंमत आणि मूल्य यांचे वर्णन असते.
6.4.1 GetDetailsOfCost पद्धतीला कॉल करण्याचे उदाहरण

aplix.Delivery ws = नवीन aplix.Delivery(); 
ws.Credentials = नवीन NetworkCredential("test", "test"); 
लांब आयडी = 168;  // CalculateShippingCost पद्धतीद्वारे प्राप्त केलेला गणना आयडी 
int TypeId = 3;  // पोस्टल वितरण

aplix.DetailsOfCost तपशील = ws.GetDetailsOfCost(ID, TypeId); 
// परिणामाचे व्हिज्युअलायझेशन 
प्रतिसाद लिहा("गणना आयडी: " + ID.ToString() + "

");
प्रतिसाद लिहा("वितरण पद्धत आयडी: " + TypeId.ToString() + "

");
प्रतिसाद.लिहा(@"

");


6.5 PushReestr पद्धत
सिंटॅक्स: लाँग पुशऑर्डर (आयडी, नंबर, तारीख, तारीख ऑफशिपमेंट, आयडी) पॅरामीटर्स:
इनपुट/आउटपुट 
प्रकार 
वर्णन
इनपुट 
स्ट्रिंग 
उपभोक्त्याच्या प्रणालीवरील नोंदणी आयडी (अद्वितीय मूल्य)
इनपुट 
स्ट्रिंग 
वितरण पर्यायाचा आयडेंटिफायर ज्यासाठी तपशील प्राप्त करणे आवश्यक आहे
इनपुट 
तारीख वेळ 
नोंदणीची तारीख (शिपमेंट स्वीकृती प्रमाणपत्रांवर छापली जाईल)
इनपुट 
तारीख वेळ 
कंत्राटदाराला माल पाठवण्याची अपेक्षित तारीख
इनपुट 
स्ट्रिंग 
या रेजिस्ट्रीमध्ये समाविष्ट केलेल्या ऑर्डर आयडेंटिफायर्सची ॲरे
पॅरामीटर नाव
आयडी
क्रमांक
तारीख
शिपमेंटची तारीख
आयडी
वर्णन: पद्धत एक्झिक्युटरच्या सिस्टमवर नोंदणी माहिती ठेवते.  ग्राहक प्रणाली नोंदणी क्रमांक आणि तारीख, एक अद्वितीय नोंदणी ओळखकर्ता आणि शिपमेंट हस्तांतरित करण्याची अपेक्षित तारीख कॉन्ट्रॅक्टरला प्रसारित करते. परतावा मूल्य:पद्धत एक्झिक्युटरच्या प्रणालीमध्ये एक अद्वितीय नोंदणी अभिज्ञापक परत करते.
6.5.1 PushReestr पद्धत कॉल करण्याचे उदाहरण

aplix.Delivery ws = नवीन aplix.Delivery(); 
ws.Credentials = नवीन NetworkCredential("test", "test"); 
// या रजिस्टरमध्ये समाविष्ट असलेल्या ऑर्डर आयडींची यादी 
स्ट्रिंग आयडी =("2013-1234567890", "2013-1234567891"); 
// क्लायंट सिस्टमवर अद्वितीय नोंदणी अभिज्ञापक 
string ID = "2013-r12345"; 
// क्लायंट सिस्टममध्ये नोंदणी क्रमांक 
स्ट्रिंग क्रमांक = "r12345"; 
// क्लायंटच्या सिस्टममध्ये रेजिस्ट्रीच्या निर्मितीची तारीख 
DateTime Date = नवीन DateTime(2013, 10, 22); 
// वितरण ऑर्डरच्या हस्तांतरणाची अंदाजे तारीख 
DateTime DateOfShipment = नवीन DateTime(2013, 10, 23); 
// गणनेचे तपशील मिळवा 
long ReestID = ws.PushReestr(ID, Number, Date, DateOfShipment, IDs); 
// परिणामाचे व्हिज्युअलायझेशन 
प्रतिसाद लिहा("रजिस्ट्री आयडी: " + ReestID.ToString() + "

");


6.6 GetTrackNumbers पद्धत
वाक्यरचना: तारीख वेळ GetTrackNumbers(DateOfLastGetting, TrackNumbers) पॅरामीटर्स:
इनपुट/आउटपुट 
प्रकार 
वर्णन
इनपुट 
तारीख वेळ 
ट्रॅक क्रमांकांच्या शेवटच्या यशस्वी पावतीची तारीख.  पॅरामीटर ट्रान्सफर केलेल्या डेटाचे प्रमाण कमी करण्यासाठी वापरले जाते आणि आधी अपलोड केलेल्या डेटाची डुप्लिकेट नाही.
इनपुट 
ट्रॅक नंबर 
ऑर्डरसाठी ट्रॅक नंबर्सची ॲरे
पॅरामीटर नाव
शेवटची तारीख
ट्रॅक नंबर
वर्णन: पद्धत DateOfLastGetting पासून वर्तमान वेळेपर्यंतच्या कालावधीसाठी ऑर्डरशी संबंधित ट्रॅक नंबरची सूची देते.  परिणाम TrackNumbers आउटपुट पॅरामीटरमध्ये ठेवला आहे.  ट्रॅक क्रमांक चालू असल्यास क्रियाकलाप गुणधर्म सत्य आहे, अन्यथा खोटे आहे.  जेव्हा शिपमेंटला एक ट्रॅक क्रमांक नियुक्त केला जातो तेव्हा परिस्थिती शक्य असते आणि काही काळानंतर दुसरा ट्रॅक क्रमांक, अशा परिस्थितीत सुरुवातीला नियुक्त केलेला ट्रॅक क्रमांक यापुढे संबंधित राहणार नाही. परतावा मूल्य:पद्धत अपलोड केलेला डेटा संबंधित असलेली तारीख आणि वेळ देते.  पुढील वेळी तुम्ही DateOfLastGetting पॅरामीटरमधील GetTrackNumbers पद्धतीला कॉल करता तेव्हा हे मूल्य वापरले जाणे आवश्यक आहे.
6.6.1 GetTrackNumbers पद्धतीला कॉल करण्याचे उदाहरण

aplix.Delivery ws = नवीन aplix.Delivery(); 
ws.Credentials = नवीन NetworkCredential("test", "test"); 
// ट्रॅकच्या शेवटच्या यशस्वी पावतीची तारीख 
DateTime DateOfLastGetting = नवीन DateTime(2013, 08, 01); 
aplix.TrackNumber TrackNumbers; 
// ट्रॅक नंबरची यादी मिळवा 
DateTime NewDateOfLastGetting = ws.GetTrackNumbers(DateOfLastGetting, Out TrackNumbers); 
// परिणामाचे व्हिज्युअलायझेशन 
प्रतिसाद लिहा("NewDateOfLastGetting: "+ NewDateOfLastGetting.ToString() +"

");
प्रतिसाद.लिहा(@"

");


API (इंग्रजी ऍप्लिकेशन प्रोग्राम इंटरफेसमधून) क्लायंटची वेबसाइट आणि सर्व्हर यांच्यातील परस्परसंवादासाठी इंटरफेस आहे.  सर्व्हर बाहेरून कामासाठी उघडतो अशा संसाधनाचे प्रतिनिधित्व करतो, उदा.  प्रोग्रामर प्रोग्राम, लायब्ररी किंवा मॉड्यूलच्या कार्यक्षमतेमध्ये प्रवेश मिळविण्यासाठी त्याचा वापर करू शकतो.  API प्रदान केलेल्या साइटची क्षमता आणि शक्ती वापरणारी संसाधने ऑपरेट करणे शक्य करते, तसेच त्यांच्यासाठी अतिरिक्त घटक लॉन्च करते जे वेब प्रकल्पाच्या क्षमतांचा विस्तार करतात.
फायदे:
प्रकार

परत येत आहे.  विनंती अनुसार तृतीय पक्ष अर्जनिर्दिष्ट पॅरामीटर्ससह कोणत्याही पद्धतीसाठी, सर्व्हर विनंती केलेली माहिती एका विशिष्ट स्वरूपात प्रदान करतो;
 
बदलत आहे  क्लायंट काही सर्व्हर फंक्शन कॉल करतो जे नवीन माहिती प्रविष्ट करते किंवा त्यावर काही सेटिंग्ज बदलते.
Yandex.Direct API
वेबसाइट प्रमोशनसाठी API प्रभावी आहे.
त्यावर आधारित, विकासक सेवेशी थेट संवाद साधणारे अनुप्रयोग तयार करू शकतात शोध इंजिन.  असे कार्यक्रम जाहिरातदारांना लवचिकपणे मोठ्या प्रमाणात जाहिरातींचे व्यवस्थापन करण्यास, त्या प्रत्येकावर सांख्यिकीय अहवाल प्राप्त करण्यास आणि अंदाजपत्रकाचा अचूक अंदाज लावू देतात.
 
डायरेक्ट API वापरून, जाहिरात एजन्सी त्यांच्या ग्राहकांची संपूर्ण यादी पाहू शकतात आणि ग्राहक त्यांचे प्रतिनिधी पाहू शकतात.
 
शोध इंजिन ऑप्टिमायझेशनसाठी वापरल्या जाणाऱ्या काही वाक्ये संदर्भित जाहिरातींमध्ये कमी CTR देत असल्यास, त्यांच्यासाठी प्रदर्शन स्वयंचलितपणे अक्षम केले जाऊ शकते.  थीमॅटिक प्लॅटफॉर्मवर, तुम्ही API द्वारे दर सेट करू शकता काही देणगीदार काढले जाऊ शकतात;
 
Yandex.Direct API मध्ये SOAP इंटरफेस आहे, म्हणजेच ते अनुप्रयोग तयार करण्यासाठी प्रोग्रामिंग भाषांची विस्तृत निवड प्रदान करते.  हा प्रोटोकॉल पर्ल, जावा, यांसारख्या भाषांद्वारे समर्थित आहे.
API सह कार्य करणे फायदेशीर आणि निराशाजनक असू शकते.  एकीकडे, इतर ऍप्लिकेशन्सशी संवाद साधून, तुम्ही प्रेक्षक पोहोचू शकता आणि तुमच्या ऍप्लिकेशनचा "वाह" प्रभाव मोठ्या प्रमाणात वाढवू शकता.  दुसरीकडे, यामध्ये अनेक दस्तऐवज वाचणे, प्रमाणीकरण धोरणांचा अभ्यास करणे आणि माहिती नसलेले (किंवा गहाळ) त्रुटी संदेश पार्स करणे समाविष्ट आहे.
सर्व प्रथम, जर तुम्हाला एपीआय (ॲप्लिकेशन प्रोग्रामिंग इंटरफेस) म्हणजे काय हे अद्याप पूर्णपणे समजले नसेल, तर स्किलक्रशचे स्पष्टीकरण वाचा आणि नंतर या लेखाचा पहिला भाग वाचा.
"API" ही एक आश्चर्यकारकपणे विस्तृत संकल्पना आहे - प्रत्येक वेळी जेव्हा तुमचा अनुप्रयोग दुसऱ्या अनुप्रयोगाशी "बोलतो", तेव्हा तो कोणत्यातरी API द्वारे असे करतो.  तुमच्या स्वत:च्या ॲप्लिकेशनमध्ये असलेले घटक, जसे की Rails चे वेगवेगळे भाग, API द्वारे एकमेकांशी बोलतात.  ते कमी-अधिक प्रमाणात स्वतंत्र उप-अनुप्रयोग आहेत जे त्यांच्यापैकी प्रत्येकाला त्यांची स्वतःची विशिष्ट कार्ये करण्यासाठी आवश्यक असलेला डेटा प्रदान करतात.  ॲपच्या जगात, प्रत्येक गोष्ट एक API आहे!
जेव्हा तुम्ही अधिक डायनॅमिक फ्रंट-एंड कार्यक्षमतेसह अनुप्रयोग तयार करता (दोन्ही एकल-पृष्ठ Javascript अनुप्रयोग आणि साधे अनुप्रयोगवेगळ्या AJAX कॉल्ससह), ते तुमच्या स्वत:च्या API द्वारे Rails बॅकएंडशी संवाद साधतील, जे तुमच्या नियंत्रकांना HTML ऐवजी JSON किंवा XML कसे सर्व्ह करावे हे सांगणारे एक किंवा दोन कोड आहेत.
या ट्युटोरियलमध्ये तुम्ही तुमचे स्वतःचे API कसे तयार करायचे ते शिकाल.  त्यानंतरच्या धड्यांमध्ये आम्ही इतर ऍप्लिकेशन्सच्या API शी संवाद कसा साधायचा ते पाहू.  या विषयाबद्दल शिकण्यासाठी धडे चांगले स्प्रिंगबोर्ड असले पाहिजेत, परंतु सर्व प्रकरणे पूर्णपणे कव्हर करण्याची शक्यता नाही.  API सह कार्य करण्याचा एक मोठा भाग म्हणजे त्यांचे दस्तऐवज कसे वाचायचे आणि त्यांना तुमच्याकडून काय हवे आहे हे जाणून घेणे.
विचारात घेण्यासारखे मुद्दे
प्रश्नांचे पुनरावलोकन करा आणि तुम्हाला उत्तरे माहित आहेत का ते पहा.  कार्य पूर्ण केल्यानंतर पुन्हा स्वतःची चाचणी घ्या.
जेव्हा तुम्ही HTTP विनंती पाठवता तेव्हा तुम्हाला प्रतिसादात कोणत्या प्रकारची फाइल अपेक्षित आहे हे Rails कसे समजते.
#respond_to पद्धतीचा उद्देश काय आहे?
तुम्ही त्या ऑब्जेक्टमध्ये समाविष्ट करू इच्छित नसलेले गुणधर्म निर्दिष्ट करताना वापरकर्ता ऑब्जेक्ट कसा परत कराल (म्हणजे, तुम्ही फक्त User.first परत करू शकत नाही)?
#to_json पद्धतीच्या पडद्यामागील 2 चरणांची नावे द्या.
तुम्ही कंट्रोलर ॲक्शनला फक्त एरर मेसेज रेंडर करण्यासाठी कसे सांगाल?
तुमचा स्वतःचा एरर मेसेज कसा तयार करायचा?
तुम्ही तुमच्या API ला प्रोग्रामॅटिक कनेक्शनला परवानगी देऊ इच्छित असल्यास तुम्ही सत्र-आधारित कंट्रोलर प्रमाणीकरण पद्धती का वापरू शकत नाही?
"सर्व्हिस ओरिएंटेड आर्किटेक्चर" म्हणजे काय?
API मूलभूत
तुमचा Rails ॲप्लिकेशन प्रत्यक्षात आधीच एक API आहे, जरी तुम्ही कदाचित त्याचा API म्हणून विचार करत नसाल.  तुमच्या वापरकर्त्यांनी लाँच केलेला वेब ब्राउझर देखील एक प्रोग्राम आहे, त्यामुळे जेव्हा वापरकर्ता उघडतो तेव्हा ते तुमच्या Rails ॲप्लिकेशनला API विनंती करते नवीन पृष्ठ.  आम्ही असा विचार करायचो कारण एचटीएमएल टेम्पलेट्स प्रस्तुत करणे हे एक सामान्य कार्य आहे की आम्ही ही कार्यक्षमता आमच्या सर्व्हर कार्यक्रमउत्तराचा मानक प्रकार म्हणून, आणि आम्ही इतर सर्व काही असामान्य मानतो.
तथापि, बऱ्याचदा तुम्हाला अशी विनंती करायची असते ज्यासाठी तुम्हाला ब्राउझर वापरण्याच्या सर्व डोकेदुखीतून जाण्याची आवश्यकता नसते.  तुम्हाला पृष्ठ संरचनेची (एचटीएमएल) काळजी नसेल, परंतु बदल्यात तुम्हाला स्वच्छ डेटा हवा आहे.  समजा तुम्हाला सर्व वापरकर्त्यांची यादी मिळवायची आहे.  तुम्ही http://yourapplication.com/users सारखे काहीतरी विनंती करू शकता, जे नक्कीच #index क्रिया ट्रिगर करेल आणि ॲपच्या सर्व वापरकर्त्यांची सूची प्रस्तुत करेल.
परंतु जर तुम्हाला फक्त वापरकर्त्यांची यादी हवी असेल तर या सर्व अतिरिक्त माहितीचा त्रास का?  समान URL वर विनंती पाठवणे आणि त्या बदल्यात JSON किंवा XML प्रतिसादाची अपेक्षा करणे हा सर्वात सोपा पर्याय आहे.  तुम्ही तुमचा Rails कंट्रोलर योग्यरितीने कॉन्फिगर केल्यास, तुम्हाला सर्व वापरकर्ते असलेला एक साधा JSON ॲरे ऑब्जेक्ट परत मिळेल.  अप्रतिम!
तुम्ही बाह्य API सह संप्रेषण करता तेव्हा समान तत्त्व लागू होते.  समजा तुम्हाला Twitter वरून वापरकर्त्याचे अलीकडील ट्वीट्स मिळवायचे आहेत.  तुम्हाला फक्त तुमच्या Rails ॲप्लिकेशनला Twitter च्या API (म्हणजे स्वतःच प्रमाणीकरण) कसे संवाद साधायचा हे सांगायचे आहे, विनंती पाठवा आणि "ट्विट्स" च्या सेटवर प्रक्रिया करा जी परत केली जाईल.
API तयार करणे
तुम्हाला तुमच्या Rails ॲप्लिकेशनला फ्रंटएंड वेब पृष्ठांसाठी एक शुद्ध बॅकएंड API बनवायचे असेल किंवा तुम्हाला फ्रन्टएंडने विनंती केल्यावर JSON कसे पाठवायचे ते शिकायचे असेल.  प्रमाणीकरण कार्यांसह पूर्ण RESTful API कसे तयार करावे हे या विभागात समाविष्ट केले जाणार नाही.  तुमच्या ॲप्लिकेशनला एपीआय म्हणून हाताळण्याचा हा एक सहज परिचय आहे.
मूलभूत
तुम्हाला तुमच्या Rails ॲप्लिकेशनने HTML ऐवजी JSON परत करायचा असल्यास, तुम्हाला तसे करण्यासाठी तुमच्या नियंत्रकाला सांगावे लागेल.  मोठी गोष्ट अशी आहे की समान नियंत्रक क्रिया परत येऊ शकते विविध प्रकारतुमचा वापरकर्ता ब्राउझरकडून नियमित विनंती करत आहे किंवा कमांड लाइनद्वारे API मध्ये प्रवेश करत आहे यावर अवलंबून आहे.  विनंती केलेल्या फाईलच्या विस्तारावर आधारित, जसे की example.xml किंवा example.json कोणत्या प्रकारची विनंती केली गेली हे हे निर्धारित करते.
सर्व्हर लॉग तपासून तुम्हाला अपेक्षित असलेल्या फाईल प्रकाराबद्दल रेलचे काय मत आहे ते तुम्ही तपासू शकता:
2013-12-02 15:21:08 -0800 वाजता 127.0.0.1 साठी GET "/posts/new" सुरू केले HTML म्हणून PostsController#new द्वारे प्रक्रिया
पहिली ओळ तुम्हाला सांगते की कोणत्या URL ची विनंती केली गेली होती आणि दुसरी तुम्हाला ती कुठे पाठवली गेली आणि रेल त्यावर प्रक्रिया कशी करते हे सांगते.  जर तुम्ही .json एक्स्टेंशन वापरत असाल तर ते असे दिसेल:
2013-12-04 12:02:01 -0800 JSON म्हणून PostsController#index द्वारे 127.0.0.1 साठी GET "/posts.json" सुरू केले
आपण धावत असल्यास चाचणी अर्ज, भिन्न URL ची विनंती करण्याचा प्रयत्न करा.  तुमचा कंट्रोलर त्यांना हाताळू शकत नसल्यास, तुम्हाला एरर येऊ शकते, परंतु तरीही तुमच्या विनंत्या Rails ला काय समजते हे पाहण्यास तुम्ही सक्षम असाल.
JSON किंवा XML प्रस्तुत करत आहे
एकदा तुम्ही JSON किंवा XML वापरून विनंत्यांना प्रतिसाद देऊ इच्छिता हे ठरवल्यानंतर, तुम्हाला तुमच्या कंट्रोलरला HTML ऐवजी JSON किंवा XML रेंडर करण्यास सांगावे लागेल.  हे करण्याचा एक मार्ग म्हणजे #respond_to पद्धत वापरणे:
वर्ग वापरकर्ते नियंत्रक< ApplicationController
 def index
 @users = User.all
 respond_to do |format|
 format.html # index.html.erb
 format.xml { render xml: @users }
 format.json { render json: @users }
 end
 end
 end
या प्रकरणात, #respond_to ब्लॉकला फॉरमॅट ऑब्जेक्ट पास करते, ज्याला तुम्ही संबंधित रेंडर कॉल संलग्न करू शकता.  तुम्ही काहीही न केल्यास, html मानक रेल टेम्प्लेट वापरून रेंडर केले जाईल (या उदाहरणात app/views/index.html.erb).
विस्तृत श्रेणीचे स्वरूप कसे रेंडर करायचे हे समजण्यासाठी #render फंक्शन पुरेसे स्मार्ट आहे.  जेव्हा तुम्ही की:json पास करता, तेव्हा ते मधील मूल्यावर #to_json कॉल करेल या उदाहरणात@ वापरकर्त्यांना.  हे तुमच्या रुबी ऑब्जेक्टचे JSON स्ट्रिंगमध्ये रूपांतर करेल जे विनंती करणाऱ्या ऍप्लिकेशनला पाठवले जाईल.
अशा प्रकारे तुम्हाला तुमचा API मिळेल.  अर्थात, जर तुम्हाला काही फॅन्सी गोष्टी करायच्या असतील तर एपीआय तयार करणे थोडे अधिक क्लिष्ट असू शकते, परंतु हे सर्व मूलभूत गोष्टींना चिकटून राहते.
परत केलेले गुणधर्म निर्दिष्ट करणे
समजा तुम्ही हे सुनिश्चित करू इच्छित आहात की तुम्ही वापरकर्ता ऑब्जेक्टसह वापरकर्त्याचा ईमेल पत्ता परत करणार नाही.  या प्रकरणात, #to_json पद्धत काय करते ते बदलून, तुम्हाला परत येणारी विशेषता बदलायची आहे.
पूर्वी, तुम्ही तुमच्या आवृत्तीसह #to_json पद्धत ओव्हरराइड केली असती, परंतु आता तुम्हाला याची आवश्यकता नाही - खरं तर, तुम्ही त्याऐवजी #as_json पद्धत ओव्हरराइड कराल.  #as_json पद्धत #to_json पद्धतीमध्ये वापरली जाते, त्यामुळे त्याचे बदल #to_json चा परिणाम स्पष्टपणे बदलतात, परंतु त्याऐवजी विशिष्ट प्रकारे.
#to_json 2 गोष्टी करते: ते #as_json चालवते आणि JSON मध्ये रेंडर केल्या जाणाऱ्या विशेषतांचा हॅश मिळवते.  ते नंतर ActiveSupport::json.encode वापरून JSON ला रेंडर करते.  त्यामुळे #as_json मध्ये बदल करून तुम्ही #to_json पद्धतीचा जो भाग बदलू इच्छिता त्याबद्दल अधिक विशिष्ट आहात.
आमच्या बाबतीत, आम्ही आमच्या मॉडेलमध्ये #as_json सुधारित करून फक्त आम्हाला आवश्यक असलेल्या विशेषता परत करतो:
# app/models/user.rb वर्ग वापरकर्ता< ActiveRecord::Base
 # Вариант 1: Полное переопределение метода #as_json
 def as_json(options={})
 { :name =>self.name ) # ईमेल फील्ड एंड समाविष्ट करू नका # पर्याय 2: मानक पद्धत वापरा #as_json def as_json(options=()) super(only: [:name]) end end
त्यानंतर, आमच्या कंट्रोलरला नेहमीप्रमाणे JSON रेंडर करणे आवश्यक असेल (खालील उदाहरणात, HTML विनंती पाठवली गेली की नाही याची पर्वा न करता, JSON नेहमी परत केला जाईल):
# app/controllers/users_controller.rb वर्ग UsersController< ApplicationController
 def index
 render json: User.all
 end
 end
लक्षात घ्या की तुम्ही #render वापरता तेव्हा तुम्हाला #to_json ला कॉल करण्याची गरज नाही - ते तुमच्यासाठी ते करेल.
कधीकधी Heroku ला तुमची त्रुटी पृष्ठे योग्यरित्या प्रदर्शित करण्यासाठी अतिरिक्त चरणांची आवश्यकता असू शकते.  इथे बघ.  तुम्हाला प्रथम ॲप/सार्वजनिक निर्देशिकेतून स्थिर पृष्ठे काढण्याची आवश्यकता असू शकते.
बाहेरून सुरक्षा सुनिश्चित करणे
वापरकर्त्याने लॉग इन केले असेल तरच तुम्ही API मध्ये प्रवेश करू इच्छिता असे समजा.  कंट्रोलरमधील तुमचे विद्यमान प्रमाणीकरण आधीच हे कार्य करते - फक्त तुमच्याकडे योग्य #before_action सेट असल्याची खात्री करा (उदा. before_action:require_login).  आपल्याला कार्यक्षमतेची आवश्यकता असू शकते जेथे लॉग-इन केलेले आणि नॉन-लॉग-इन केलेले दोन्ही वापरकर्ते पृष्ठ पाहू शकतात, परंतु प्रत्येकाला भिन्न डेटा दिसला पाहिजे.  तुम्हाला अनधिकृत वापरकर्त्यांनी संवेदनशील डेटा मिळवण्यासाठी API कॉल करता यावेत असे वाटत नाही.  त्याचप्रमाणे, आपण अनधिकृत वापरकर्त्यांना विशिष्ट HTML पृष्ठांना भेट देण्याची परवानगी देऊ इच्छित नाही.
तुम्हाला ब्राउझर नसलेल्या ॲप्लिकेशनच्या विनंत्या हाताळायच्या असल्यास (उदाहरणार्थ, पासून कमांड लाइन), तुम्ही प्रमाणीकरणासाठी ब्राउझर कुकीजवर अवलंबून राहू शकत नाही.  म्हणूनच बहुतेक API प्रमाणीकरण प्रक्रियेचा भाग म्हणून मूळ टोकन वापरतात.  आपण पुढील धड्यात टोकन्सबद्दल थोडे अधिक बोलू.
पुढील पायऱ्या
तुमच्याकडे आता फक्त एचटीएमएलच नाही तर इतर कोणतेही फॉरमॅट रेंडर करण्यासाठी तुमचा Rails ॲप्लिकेशन वापरण्याचे कौशल्य आहे.  जर तुम्हाला आणखी पुढे जायचे असेल आणि इतर डेव्हलपरना तुमचा प्लॅटफॉर्म वापरून गोष्टी तयार करण्याची अनुमती द्यायची असेल (उदाहरणार्थ, ते वापरकर्ता म्हणून प्रमाणीकरण करण्याऐवजी प्रोग्रामॅटिक विनंत्या करू शकतात), तुम्हाला तुमची API प्रणाली अधिक मजबूत करणे आवश्यक आहे.  आम्ही हे सर्व येथे कव्हर करणार नाही, परंतु खालील तपासा:
बिल्डिंग अप्रतिम रेल APIs हा लेख खेळण्यांच्या ऍप्लिकेशनमधून औद्योगिक API मानकांकडे जाण्यासाठी अनेक सर्वोत्तम पद्धतींचे वर्णन करतो.
सेवा-देणारं वास्तुकला
सर्व्हिस-ओरिएंटेड आर्किटेक्चर (SOA) नावाचा आर्किटेक्चरल दृष्टीकोन सादर करण्याची ही वेळ आहे.  मूळ कल्पना अशी आहे की तुमच्या अर्जामध्ये अनेक सेवा असतील, जसे की पेमेंट सिस्टम, वापरकर्ता नोंदणी, शिफारस मॉड्यूल इ.  हे सर्व एका मुख्य अनुप्रयोगात तयार करण्याऐवजी, तुम्ही उपप्रणाली पूर्णपणे स्वतंत्र तुकड्यांमध्ये मोडता जे अंतर्गत API वापरून एकमेकांशी संवाद साधतात.
हे अनेक कारणांसाठी चांगले आहे.  तुमच्या ॲप्लिकेशनच्या प्रत्येक भागाला इतर भाग कसे कार्य करतात याकडे लक्ष देत नसल्यामुळे आणि फक्त त्यांच्या API द्वारे डेटाची विनंती कशी करायची हे माहीत असल्याने, तुम्ही सेवा कोडमध्ये महत्त्वपूर्ण बदल करू शकता आणि उर्वरित अनुप्रयोग पूर्वीप्रमाणेच कार्य करेल.  तुम्ही एक सेवा पूर्णपणे बदलून दुसरी सेवा देऊ शकता आणि जोपर्यंत ती समान API पद्धती वापरून संवाद साधते तोपर्यंत ती अगदी सहजतेने जाईल.  तुम्ही तुमचे स्वतःचे लिहिण्याऐवजी तुमच्या ऍप्लिकेशनचा भाग म्हणून (उदा. पेमेंट सिस्टम) बाह्य API वापरू शकता.  तुम्ही PHP ॲप्लिकेशन तयार करू शकता जो पायथन ॲप्लिकेशनसह संप्रेषण करतो जो रेल ॲप्लिकेशनसह संप्रेषण करतो आणि सर्वकाही कार्य करेल कारण ते API वापरून एकमेकांशी संवाद साधतात.
तुमच्या अर्जाचा प्रत्येक भाग शक्य तितका स्वतंत्र करण्याचा प्रयत्न करणे सामान्यतः चांगली कल्पना आहे.  SOA ची संकल्पना तुम्हाला तुमच्या ऍप्लिकेशनच्या इतर भागांमध्ये कोणत्या पद्धतींचा पर्दाफाश करायचा आहे याचा विचार करण्यास भाग पाडते, ज्यामुळे तुमचा कोड देखील चांगला होईल.  याशिवाय, तुमच्या अर्जाचा प्रत्येक प्रमुख घटक स्वतंत्र आहे असे गृहीत धरून, तुम्ही समस्या अधिक सहजतेने वेगळे करण्यात आणि त्रुटी अधिक अर्थपूर्ण पद्धतीने हाताळण्यास सक्षम असाल.
संपूर्ण ऍप्लिकेशनसाठी सेवा-देणारं आर्किटेक्चर वापरणे म्हणजे एका विशाल, जटिल रुबी स्क्रिप्टला व्यवस्थित वर्ग आणि पद्धतींमध्ये विभाजित करण्यासारखे आहे, फक्त मोठ्या प्रमाणावर.
सेवा-देणारं आर्किटेक्चरमध्ये संक्रमणाची सर्वात प्रसिद्ध प्रकरणांपैकी एक म्हणजे Amazon.com.  2002 मध्ये एके दिवशी, जेफ बेझोस यांनी स्पष्टपणे सांगितले की सर्व कार्यसमूहांनी SOA मध्ये जाणे आवश्यक आहे किंवा त्यांना काढून टाकले पाहिजे.  बदनाम ब्लॉग पोस्ट Google कर्मचारी, अंतर्गत हेतूंसाठी हेतू परंतु चुकून सार्वजनिक केले, SOA वापरून Amazon च्या सामर्थ्याबद्दल बोलले.  हे एक उत्तम वाचन आहे, म्हणून ते तपासण्याचे सुनिश्चित करा, परंतु बेझोसच्या पत्रातील मुख्य मुद्दे पोस्टमधील खालील अवतरणांमध्ये सारांशित केले आहेत:

1) सर्व संघ आता सेवा इंटरफेसद्वारे त्यांचा डेटा आणि कार्यक्षमता प्रदान करतात.
२) संघांनी या इंटरफेसद्वारे एकमेकांशी संवाद साधला पाहिजे.
3) इंटरप्रोसेस कम्युनिकेशनचे इतर प्रकार प्रतिबंधित आहेत: कोणतेही थेट दुवे नाहीत, दुसऱ्या कमांडच्या डेटाचे थेट वाचन नाही, सामायिक मेमरी मॉडेल नाहीत, बॅकडोअर्स नाहीत इ.  परस्परसंवादाचा एकमेव मार्ग म्हणजे नेटवर्कवरील सेवा इंटरफेसमध्ये प्रवेश करणे.
4) ते कोणते तंत्रज्ञान वापरतात हे महत्त्वाचे नाही.  HTTP, Corba, Pubsub, स्वामित्व प्रोटोकॉल - फरक नाही.  बेझोसला त्याची पर्वा नाही.
5) सर्व सेवा इंटरफेस, अपवादाशिवाय, सुरुवातीला बाह्यरित्या नियंत्रित करण्याच्या क्षमतेसह डिझाइन केलेले असणे आवश्यक आहे.  म्हणजेच, संघाने कंपनीच्या बाहेरील विकासकांना इंटरफेस प्रदान करण्यास सक्षम होण्यासाठी योजना आणि डिझाइन करणे आवश्यक आहे.  अपवाद नाही.
6) जो कोणी या आवश्यकतांकडे दुर्लक्ष करतो त्याला काढून टाकले जाईल.

SOA हा गंभीर व्यवसाय आहे.  नक्कीच, ते वापरताना अनेक समस्या येतात - Amazon च्या "शिकलेले धडे" बद्दल ही पोस्ट पहा - परंतु त्याचे अविश्वसनीय प्रमाणात फायदे आहेत.
तुम्ही स्वत:साठी खेळणी ॲप्स तयार करत असताना तुम्हाला कदाचित SOA बद्दल जास्त काळजी वाटणार नाही, परंतु तुम्ही IT कंपनीसाठी काम सुरू केल्यावर ही समस्या नक्कीच समोर येईल, त्यामुळे स्वतःला त्याची ओळख करून घेणे हा एक चांगला सराव आहे.
आपले ध्येय
JSON आणि XML रेंडरिंगबद्दल जाणून घेण्यासाठी Rails Controllers Guide चा विभाग 7 वाचा.
त्यांना पाहण्याची आवश्यकता नाही (कारण ते आम्ही सध्या तयार आहोत त्यापेक्षा थोडे पुढे जातात), परंतु तुम्हाला स्वारस्य असल्यास, अधिक जाणून घेण्यासाठी धड्याच्या तळाशी असलेल्या अतिरिक्त संसाधन विभागातील रेलकास्ट पहा. API चे फायदे.
निष्कर्ष
Javascript अभ्यासक्रमादरम्यान आम्ही API म्हणून तुमच्या अर्जावर अधिक लक्षपूर्वक काम करू.  या कोर्समध्ये, तुम्ही अनेक फुल-स्टॅक ॲप्लिकेशन्स तयार कराल जे AJAX कॉल्स चांगल्या प्रकारे वापरतात वापरकर्ता इंटरफेस, ज्यामध्ये संपूर्ण HTML पृष्ठाऐवजी XML किंवा JSON डेटा प्रस्तुत करणे समाविष्ट आहे.  त्यानंतर तुम्ही अनेक सिंगल-पेज Javascript ॲप्लिकेशन्स तयार कराल जे डेटाबेसमधून सर्व आवश्यक डेटा आणण्यासाठी तुमच्या Rails ॲप्लिकेशनद्वारे प्रदान केलेल्या API वर अवलंबून असतात, परंतु अन्यथा क्लायंटच्या बाजूने (ब्राउझरमध्ये) चालतात.
एपीआय समजून घेण्याचा सर्वोत्तम मार्ग म्हणजे ते तयार करणे आणि त्याच्याशी संवाद साधणे, ज्यावर आम्ही आमच्या प्रकल्पांमध्ये लक्ष केंद्रित करू.