बाकी एपीआई - मोबाइल विशिष्ट चुनौतियां

Question

मैं एक नई iOS ऐप परियोजना पर काम कर रहा हूं, मोबाइल पक्ष पर। कुछ आर्किटेक्चर परिवर्तन हो रहे हैं और यह पता चलता है कि हमें एक कस्टम निर्मित निजी एपीआई पर भरोसा करना होगा जिसका उपयोग हम उस ऐप के द्वारा किया जाएगा और अन्य क्लाइंट जैसे कि वेबसाइट।

डिज़ाइन किया जा रहा एपीआई संसाधनों की केंद्रित शैली URI और CRUD संचालन के लिए HTTP क्रियाओं के लिए मैप की गई है। इस तरह की चीजें:

GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793

समस्या यह है कि यह शैली अक्सर मोबाइल क्लाइंट के लिए एकल एप्लिकेशन स्क्रीन लोड करने या एकल उपयोगकर्ता UI कार्रवाई प्रबंधित करने के लिए कई अनुरोध करने की आवश्यकता होती है। यह एप्लिकेशन को 8 सेकंड के लिए लोडिंग मोड में रखता है, जब तक कि उसके पास सब कुछ आवश्यक न हो। एक धीमी और अनुत्तरदायी अनुप्रयोग।

जब कनेक्टिविटी की बात आती है तो मोबाइल क्लाइंट की गंभीर सीमाएँ होती हैं और आदर्श रूप में, हमें उस तरह के नियम का पालन करना चाहिए:

1 स्क्रीन == 1 एपीआई कॉल

1 सेव == 1 एपीआई कॉल।

ऐसी कई स्थितियाँ हैं, जहाँ यह आपको उदाहरण के लिए REST डिज़ाइन सिद्धांतों के साथ टकराव के पाठ्यक्रम पर रखती है:

• मान लीजिए कि आपका एप्लिकेशन एक दिन के लिए ऑफ़लाइन हो गया है और आपको बैक-एंड डेटाबेस की चार तालिकाओं के साथ सिंक करने की आवश्यकता है और आपको कॉल की आवश्यकता है www.example.com/sync_everything?since=2015-07-24
• मान लीजिए कि एक स्क्रीन है जहां उपयोगकर्ता अपनी कई वस्तुओं को संपादित कर सकता है, उदाहरण के लिए उसकी टूडू सूची में कार्यों को टिक करना। प्रति एक एपीआई कॉल के बजाय एक एकल बैच एपीआई कॉल में उन सभी कार्यों के रिकॉर्ड को संपादित करने का एक तरीका होना चाहिए।
• मान लीजिए कि एक स्क्रीन है जो ORDER, SALESMEN और PRODUCT db तालिकाओं की जानकारी को मिलाती है, मुझे उस डेटा को तीन के बजाय एक कॉल में प्राप्त करना चाहिए।

जोखिम यह है कि हम सबसे अधिक आराम करने वाले एपीआई के साथ समाप्त हो सकते हैं और वहाँ सबसे बेकार अनुत्तरदायी मोबाइल ऐप भी है।

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

या इस सामान्य समस्या के लिए कोई समाधान। धन्यवाद!

Comments

ऐसा लगता है कि आपका प्रश्न यह हो सकता है, "राईन शैली को बनाए रखते हुए एक एपीआई किस तरह या इसके विपरीत या इसके विपरीत वस्तुओं के संग्रह को वितरित कर सकता है?" क्या मैं आपका प्रश्न समझ रहा हूँ?

— joshp

मेरा मानना ​​है कि सामान्य उत्तर यह है कि प्रत्येक REST कॉल को विभिन्न प्रकार के वैकल्पिक मापदंडों को लेने की आवश्यकता होती है, इसलिए यह लचीला हो सकता है फिर भी अपेक्षाकृत सहज हो सकता है। सिंकिंग केस हमेशा पेचीदा होगा, लेकिन नियमित पेजों के लिए आप सामान्य रूप से एक ही प्रकार के कई कॉल देख रहे होते हैं , यानी सभी सही?

— Ixrec

मुझे लगता है कि आपके एपीआई को एडॉप्ट करना गलत समाधान है जब समस्या समानांतर अनुरोधों की कमी है - 8 छोटे अनुरोध एक बड़े अनुरोध की तुलना में बहुत खराब नहीं होते हैं जब उन्हें एक-दूसरे के लिए इंतजार नहीं करना पड़ता है। क्या आप HTTP / 2 पर स्विच कर सकते हैं? या कम से कम HTTP / 1.1 पाइपलाइनिंग का उपयोग करें?

— आमोन

यह भी देखें: REST वेब सेवाओं में बैच संचालन से निपटने के लिए पैटर्न? । कुंजी यह पहचान कर रही है कि किस प्रकार के कमांड (और किस पूर्व शर्त के तहत) बिना किसी संघर्ष के एक साथ बैच हो सकते हैं, और फिर बैच किए गए ऑर्डर का JSON प्रतिनिधित्व बना सकते हैं, और फिर इसे भेज सकते हैं। यह REST के लिए मुख्य आकर्षण खो देता है जो कि इसकी कैचेबिलिटी है लेकिन cacheability हमेशा सभी प्रकार के अनुप्रयोगों के लिए प्रासंगिक नहीं होती है। नोट करें कि तार्किक निर्भरताएँ होने पर बैच / संगामिति लागू नहीं होती है।

— rwong

उस स्थिति के लिए एक सादृश्य जहां बिचौलिये को प्रत्येक अनुक्रम में गैर-तुच्छ तार्किक निर्भरता के साथ एक क्रम में कई ऑपरेशन करने की आवश्यकता होती है, "संग्रहित प्रक्रिया" की तरह कुछ है, जिसे डेटाबेस के अंदर के बजाय उस बिचौलिया में निष्पादित किया जाता है। नीचे, बिचौलिये को एक "संग्रहित प्रक्रिया" कॉल को आवश्यकतानुसार कई रिस्टफुल अनुरोधों में बदलने की अनुमति है, लेकिन यह बिचौलिया का कार्यान्वयन विवरण है।

— rwong

Answer 1

डिज़ाइन किया जा रहा एपीआई संसाधनों की केंद्रित शैली URI और CRUD संचालन के लिए HTTP क्रियाओं के लिए मैप की गई है।

यहीं आपकी समस्या है।

आपने अपने डेटाबेस में अपने संसाधनों को (मैं मान रहा हूँ) सीमित कर दिया है। जैसे कि इन सभी संसाधनों को लोड करने में उम्र लग रही है क्योंकि आपके सर्वर में उन संसाधनों की कोई अवधारणा नहीं है जिनका डेटाबेस में प्रतिनिधित्व नहीं है।

उदाहरण के लिए हो सकता है

www.example.com/books/482094
www.example.com/books/582045
www.example.com/books/427454
www.example.com/books/319343

मेरी लाइब्रेरी पाने के लिए सभी को लोड करना होगा

यह Restful डिजाइन के साथ कोई समस्या नहीं है, यह एक वास्तविक विरोधी पैटर्न है। REST में कुछ भी ऐसा नहीं है जो कहता है कि हमारे संसाधनों में आपके सिस्टम में डेटाबेस मॉडल सहित किसी भी चीज़ के साथ एक से एक मैपिंग होनी चाहिए।

इसका समाधान यह है कि आप अधिक संसाधनों का निर्माण करें जो बेहतर है कि आप क्या लोड करना चाहते हैं। यदि आपके पास 5 संसाधन हैं जो हमेशा एक साथ समाप्त होते हैं तो एक नया संसाधन बनाते हैं जिसमें उन 5 संसाधनों के लिए जानकारी होती है।

आपके पास ऐसा कुछ होना चाहिए

www.example.com/users/334/my_library

जो सिर्फ उस उपयोगकर्ता के लिए सभी पुस्तकों को लोड करता है। "my_library" आपके डेटाबेस में एक मॉडल नहीं है, लेकिन यह एक संसाधन है। सर्वर डेटाबेस में मॉडल के आधार पर इसे बनाता है, लेकिन कोई 1-टू -1 मैपिंग नहीं है और सर्वर में आपके DB मॉडल को बदले बिना इस संसाधन को बनाने के लिए लचीलापन है।

आपके पास भी हो सकता है

www.example.com/users/334/favioured_books
www.example.com/users/334/books_ordered_last_week
www.example.com/users/334/wishlist

जिनमें से किसी को भी आपके डेटाबेस या डोमेन स्पेस में मॉडल के रूप में मौजूद होना चाहिए।

एक व्यापक प्रसार की भ्रांति है कि यह गलत काम है क्योंकि रेल जैसी रूपरेखाओं ने लोगों को डोमेन स्पेस में मॉडल से 1-टू -1 फैशन में संसाधनों को मैप करने के लिए सिखाया जो डेटाबेस पंक्तियों के साथ फिर से 1-टू -1 मैप करते हैं। यह आवश्यक नहीं है और न ही यह अनुशंसित है।

संसाधन कई, सस्ते और हल्के होने चाहिए । उन्हें बनाना आसान होना चाहिए, और उन्हें आपके डोमेन मॉडल से अलग होना चाहिए। यदि आप पाते हैं कि आपको एक नया चाहिए तो आप एक नया बना सकते हैं। यदि आपको ऐसा करने में समस्या है, तो यह आपके फ्रेमवर्क की गलती है, न कि REST के साथ।

अब उस पाठ्यक्रम के साथ बड़ी चेतावनी यह है कि क्या आपका ढांचा आपको ऐसा करने की अनुमति देता है। रेल और Django जैसी रूपरेखाओं ने "आपको समय बचाने के लिए" 1-टू -1 का नक्शा बनाने के लिए लिया है ताकि ऐसा करने में मुश्किल हो। लेकिन यह फ्रेमवर्क के साथ दोष है, रेस्टफुल डिज़ाइन के साथ नहीं।

यहाँ जिम वेबर इस पर चर्चा कर रहा है और अधिक विस्तार से (साथ ही रेल पर कुछ डगों सहित!)

https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047

Comments

यह बहुत दिलचस्प है और मैं इससे पूरी तरह सहमत हूं लेकिन दुख की बात यह है कि मैं एपीआई नहीं कर रहा हूं और मेरे पास इसे प्रभावित करने का बहुत कम तरीका है, यदि कोई हो। बहुत से लोग उस "एंटी-पैटर्न" का उपयोग सभी के लिए करेंगे (कई कारणों से, फ्रेमवर्क सीमाएं एक हैं) और वे सिर्फ अपने डेटाबेस के बारे में स्पष्ट रूप से सोचने के लिए यूआरआई परिभाषा का उपयोग करते हैं। एपीआई एंडपॉइंट्स उनके DB की कल्पना करने का सिर्फ एक और तरीका है ... इसके अलावा, कुछ मामलों में, आपके द्वारा वर्णित संसाधन को बनाना मुश्किल है क्योंकि ऑब्जेक्ट ऑब्जेक्ट वास्तव में अलग हैं, बस उनका नामकरण बहुत अस्पष्ट शब्दों को जन्म देगा।

— MikaelW

एक दक्षता कोण से इस मुद्दे पर वापस जाने के लिए, वे इस बात पर सहमत हुए कि अगर मोबाइल स्क्रीन बहुत धीमी है (और केवल अगर ऐसा हुआ है), तो कुछ समग्र कॉल संभव होंगे लेकिन वे एक घटक में बैठे होंगे जो एपीआई के चारों ओर लपेटता है ( स्वयं API के बजाय), केवल मोबाइल क्लाइंट द्वारा उपयोग किया जाएगा और कोर API, कोर डोमेन के भाग के रूप में नहीं माना जाएगा।

— MikaelW

@ मायकावेल, आप सही कह रहे हैं। यहां तक ​​कि कॉर्मैक ने जो कहा है वह आदर्श परिदृश्य है, कुछ बार जब आप एक एपीआई के साथ काम कर रहे होते हैं, जिसमें बहुत सारे अन्य सिस्टम (डेस्कटॉप, मोबाइल, वेब, अनुसूचित नौकरी, विरासत प्रणाली, आदि) की आवश्यकता होती है। इस तरह की एपीआई को वास्तव में लचीला होना चाहिए, जिससे संसाधनों को यथासंभव अधिक संभावनाएं मिल सकें, लेकिन एक उपभोक्ता से सभी विशिष्ट प्रदर्शन आवश्यकताओं को पूरा नहीं किया जा सकता है। उस मामले में आपके पास कई विकल्प नहीं हैं ...

— Dherik