क्यों REST Api मुखौटा डिजाइन पैटर्न का पालन नहीं करता है

Question

एक OO मॉडल के साथ REST [api] संरचना की तुलना में, मुझे ये समानताएं दिखाई देती हैं:

दोनों:

• क्या डेटा ओरिएंटेड हैं

  • REST = संसाधन
  • ऊ = वस्तुएँ

• डेटा के आसपास संचालन

  • REST = चारों ओर VERBS (Get, Post, ...) संसाधनों के आसपास
  • OO = इनकैप्सुलेशन द्वारा ऑब्जेक्ट्स के आसपास ऑपरेशन को बढ़ावा देना

हालाँकि, अच्छा OO अभ्यास हमेशा REST एपिस पर नहीं खड़ा होता है जब उदाहरण के लिए मुखौटा पैटर्न लागू करने की कोशिश की जाती है: REST में, आपके पास सभी अनुरोधों को संभालने के लिए 1 नियंत्रक नहीं है और आप आंतरिक ऑब्जेक्ट जटिलता को नहीं छिपाते हैं।

इसके विपरीत, REST संसाधन और अन्य के साथ कम से कम दो रूपों में सभी संबंधों के प्रकाशन को बढ़ावा देता है:

1. संसाधन पदानुक्रम संबंधों के माध्यम से (आईडी 43 का एक संपर्क 453 पते से बना है): /api/contacts/43/addresses/453

2. REST json प्रतिक्रिया में लिंक के माध्यम से:

>> GET /api/contacts/43
<< HTTP Response {
   id: 43, ...
   addresses: [{
      id: 453, ...
   }],
   links: [{
      favoriteAddress: {
          id: 453
      }
   }]
}

OO में वापस आकर, मुखौटा डिज़ाइन पैटर्न Low Couplingकिसी ऑब्जेक्ट और उसके ' ऑब्जेक्ट ' क्लाइंट के बीच और High Cohesionइस ऑब्जेक्ट और इसके आंतरिक ऑब्जेक्ट कंपोज़िशन ( objectC , objectD ) के लिए सम्मान करता है । साथ objectA इंटरफेस, इस पर सीमा प्रभाव के लिए एक डेवलपर के लिए अनुमति देते objectB की objectA आंतरिक परिवर्तन (में objectC और objectD ), जब तक कि objectA एपीआई (संचालन) अभी भी सम्मान किया जाता है।

REST में, डेटा (संसाधन), संबंध (लिंक), और व्यवहार (क्रिया) विभिन्न तत्वों में विस्फोट होते हैं और वेब पर उपलब्ध होते हैं।

REST के साथ खेलने पर, मेरे ग्राहक और सर्वर के बीच कोड परिवर्तन पर हमेशा प्रभाव पड़ता है: क्योंकि मेरे पास High Couplingमेरे Backbone.jsअनुरोधों और Low Cohesionसंसाधनों के बीच है।

मैं कभी नहीं पता चल मेरे जाने के लिए कैसे Backbone.js javascript applicationके साथ सौदा " बाकी संसाधनों और सुविधाओं " खोज बाकी लिंक द्वारा पदोन्नत। मैं समझता हूं कि डब्ल्यूडब्ल्यूडब्ल्यू को बहु सर्वरों द्वारा सेवा देने के लिए है, और यह कि ओओ तत्वों को वहां कई मेजबानों द्वारा सेवित किया जाना था, लेकिन एक सरल परिदृश्य जैसे "पृष्ठ" को बचाने के लिए, जो अपने पते के साथ संपर्क दिखाता है, मैं इसके साथ समाप्त होता हूं:

GET /api/contacts/43?embed=(addresses)
[save button pressed]
PUT /api/contacts/43
PUT /api/contacts/43/addresses/453

जो मुझे ब्राउज़रों के अनुप्रयोगों (दो संसाधनों को अलग से संबोधित किया जा सकता है) पर बचत कार्रवाई परमाणु लेनदेन संबंधी जिम्मेदारी को आगे बढ़ाने के लिए नेतृत्व करता है।

इसे ध्यान में रखते हुए, अगर मैं अपने विकास को सरल नहीं बना सकता (मुखौटा डिजाइन पैटर्न लागू नहीं है), और अगर मैं अपने ग्राहक के लिए और अधिक जटिलता लाता हूं (लेन-देन परमाणु बचत को संभालना), तो RESTful होने का लाभ कहां है?

Comments

मुझे समझने दो। आप कह रहे हैं कि आपको दो REST कॉल का उपयोग करके एक "एम्बेडेड" (रचना) लिंक किए गए पते के साथ एक संपर्क अपडेट करना है, एक संपर्क के लिए और दूसरा इसके पते के लिए। संपर्क अपडेट करने के लिए आपके पास एक मुखौटा है। PUT /api/contacts/43आंतरिक वस्तुओं के अपडेट को कैस्केड करने के साथ समस्या क्या है ? मेरे पास इस तरह से डिज़ाइन किए गए बहुत सारे एपीआई थे (मास्टर URL "पूरे" को पढ़ता / बनाता है / अपडेट करता है और उप-यूआरएल टुकड़ों को अपडेट करता है)। बस यह सुनिश्चित करें कि जब कोई बदलाव आवश्यक न हो (प्रदर्शन कारणों से) तो आप पते को अपडेट न करें।

— एंथोनी एकॉली

@AnthonyAccioly, आपने सही ढंग से समझा। मैंने कुछ छवियों को जोड़कर अपने प्रश्न को स्पष्ट करने का प्रयास किया। आपका सुझाव अच्छा है और वह निष्कर्ष भी है जिसके साथ मैं आया था: मैन्युअल रूप से मेरे अनुरोध को नियंत्रित करने और अपने अद्यतन को रखने के लिए केवल एक अनुरोध भेजने के लिए एक एम्बेडेड ऑब्जेक्ट का उपयोग करें। फिर भी: क्यों REST में सब कुछ मुझे मेरे मॉडल को समतल करके (कई नियंत्रकों को लागू करके) OO गुणों या प्रवर्तन (एन्कैप्सुलेशन, ...) से दूर धकेल देता है। अपने समाधान का उपयोग करना 1 परमाणु अद्यतन देता है। अपने समाधान का उपयोग नहीं करने से एक डेवलपर नई जिम्मेदारी आती है और उसे करने से रोकने के लिए एपीआई पर कोई नियम नहीं है।

— एलेन

बस एक नोट: आपके द्वारा उल्लिखित "संसाधन पदानुक्रम संबंध" इस बात का है कि कोई व्यक्ति किसी पहचानकर्ता (इस मामले में, URL) में संबंध जानकारी को कैसे एनकोड करने का निर्णय ले सकता है। मुझे यकीन नहीं है कि यह जानकारी का विस्तार कुछ ऐसा है जो REST का हिस्सा है या ऐसा कुछ है जो इसे बढ़ावा देता है, बस एक निर्णय एक सिस्टम के URL के साथ आने पर खुद करता है। यदि आप अन्यथा मानते हैं, तो क्या आपके पास रॉय फील्डिंग का कोई संदर्भ है जो इस मामले को REST के हिस्से के रूप में चर्चा कर रहा है?

— थियागो सिल्वा

Answer 1

मुझे लगता है कि वस्तुओं को केवल सुसंगत व्यवहार के आसपास ही बनाया गया है न कि डेटा के आसपास। मैं उकसाऊंगा और कहूंगा कि वस्तु उन्मुख दुनिया में डेटा लगभग अप्रासंगिक है। वास्तव में, यह संभव है और कुछ समय पहले ऐसी वस्तुएं होती हैं जो कभी भी डेटा नहीं लौटाती हैं, उदाहरण के लिए "लॉग सिंक", या ऑब्जेक्ट जो कभी पारित किए गए डेटा को वापस नहीं करते हैं, उदाहरण के लिए यदि वे सांख्यिकीय गुणों की गणना करते हैं।

आइए हम PODS को भ्रमित न करें , (जो संरचनाओं की तुलना में थोड़ा अधिक हैं), और वास्तविक वस्तुएं जिनके व्यवहार हैं (जैसे Contactsआपके उदाहरण में वर्ग) ¹ ।

PODS मूल रूप से रिपॉजिटरी और व्यावसायिक वस्तुओं से बात करने के लिए उपयोग की जाने वाली सुविधा है। वे कोड को सुरक्षित रखने की अनुमति देते हैं। न आधिक न कम। दूसरी ओर, व्यावसायिक वस्तुएं, ठोस व्यवहार प्रदान करती हैं , जैसे आपके डेटा को मान्य करना, या इसे संग्रहीत करना, या इसका उपयोग करके गणना करना।

तो, व्यवहार वह हैं जो हम "सामंजस्य" ² को मापने के लिए उपयोग करते हैं , और यह देखना काफी आसान है कि आपके ऑब्जेक्ट उदाहरण में कुछ सामंजस्य है, भले ही आप शीर्ष स्तर के संपर्कों में हेरफेर करने के तरीकों को दिखाते हैं और पते में हेरफेर करने के लिए कोई तरीके नहीं हैं।

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

स्पष्ट रूप से, आरईएसटी सेवाओं में उच्च सामंजस्य होता है (संसाधन के साथ बातचीत करने का हर तरीका एक ही स्थान पर होता है) और कम युग्मन (प्रत्येक संसाधन भंडार को दूसरों के ज्ञान की आवश्यकता नहीं होती है)।

मूल तथ्य यह है कि, हालांकि, REST मूल रूप से आपके डेटा के लिए एकल रिपॉजिटरी पैटर्न है । इसके परिणाम हैं, क्योंकि यह एक धीमी गति से आसान पहुंच के आसपास बनाया गया एक प्रतिमान है, जहां "गपशप" के लिए एक उच्च लागत है: ग्राहक आमतौर पर जितना संभव हो उतना कम संचालन करना चाहते हैं, लेकिन एक ही समय में उन्हें आवश्यक डेटा प्राप्त होता है । यह निर्धारित करता है कि आप कितने डेटा ट्री को वापस भेजने जा रहे हैं।

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

यह अब तक स्पष्ट होना चाहिए कि ओओ अवधारणाओं के साथ डेटा डिजाइन का विश्लेषण करना इसे मापने का एक विश्वसनीय तरीका नहीं है: यह सेब और संतरे की तुलना करने जैसा है!

वास्तव में, यह पता चला है कि रेस्टफुल होने के फायदे (ज्यादातर) ऊपर उल्लिखित हैं: यह धीमी गति से साधारण एपीआई के लिए एक अच्छा पैटर्न है। यह बहुत ही आसानी से मिल सकने योग्य और शार्पेबल है। चटपटेपन आदि पर इसका ठीक-ठाक नियंत्रण होता है।

मुझे आशा है कि यह आपके (बहुविध) प्रश्न का उत्तर देता है :-)

---

^{1 यह समस्या ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल के रूप में ज्ञात समस्याओं के एक बड़े समूह का हिस्सा है । ओआरएम के प्रस्तावक आम तौर पर शिविर में होते हैं जो डेटा विश्लेषण और व्यवहार विश्लेषण के बीच समानता की पड़ताल करते हैं , लेकिन ओआरएम देर से आलोचना के तहत गिर गए हैं क्योंकि उन्हें लगता है कि वास्तव में प्रतिबाधा बेमेल को हल नहीं किया जाता है और उन्हें लीक सार माना जाता है ।}

^{2 http://en.wikipedia.org/wiki/Cohesion_(computer_science)}

Comments

आप सही कह रहे हैं, मेरे पास कई पहलुओं में अपने प्रश्न को विस्फोट करने के लिए एक विशिष्ट बिंदु को खत्म करने के लिए कठिन समय था, क्योंकि प्रश्न इन पहलुओं के संचय के आधार पर एक "गलत" निष्कर्ष को संबोधित करता है। मैं कई टिप्पणियों में आपके बिंदुओं का जवाब देने की कोशिश करूंगा।

— Alain

[पाठ 1] मैंने "डेटा" शब्द का उपयोग OO और REST दुनिया से अमूर्त करने के लिए किया। OO में डेटा और REST में डेटा संरचना के लिए आप किस शब्द का उपयोग करेंगे?

— Alain

@ "डेटा" ठीक है, लेकिन मेरी बात PODS और व्यावसायिक वस्तुओं को भ्रमित करने के लिए नहीं है। जब हम OOD के बारे में बात करते हैं तो हम आम तौर पर दूसरे के बारे में बोलते हैं। पहले एक सुविधा है, और यह लगभग एक शब्दकोश या संरचना या टपल के बारे में आसानी से सोचा जा सकता है।

— स्किलिविज़

हां, मैं सहमत हूं, मैं बैकबोन.जेएस का उपयोग करता हूं जहां एक मॉडल को बचाने के लिए एक साधारण जसन संरचना का उपयोग किया जाता है। यह वह जगह है जहाँ पाठ मेरे वास्तविक कोडिंग अनुभव को दर्शाता है।

— एलैन

[पाठ ३] यह मेरे लिए नया है। मैंने सोचा था कि सामंजस्य को समय की संख्या से मापा जाता था, एक विशिष्ट संबंध का उपयोग करते हैं ... मैं इसे देखने के आपके तरीके को पसंद करता हूं।

— Alain

Answer 2

इसे ध्यान में रखते हुए, अगर मैं अपने विकास को सरल नहीं बना सकता (मुखौटा डिजाइन पैटर्न लागू नहीं है), और अगर मैं अपने ग्राहक के लिए और अधिक जटिलता लाता हूं (लेन-देन परमाणु बचत को संभालना), तो RESTful होने का लाभ कहां है?

"जवाब देने योग्य होने का लाभ कहाँ है?" यहाँ पूरी तरह से विश्लेषण और समझाया गया है: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

इस प्रश्न में भ्रम यह है कि यह REST की विशेषताओं के बारे में नहीं है और उन्हें कैसे सामना करना है, लेकिन यह मानकर कि आपके उदाहरण प्रणाली के लिए आपके द्वारा आए URL के डिज़ाइन को RESTful होने के साथ कुछ करना है। आखिरकार, आरईएसटी कहता है कि संसाधन नामक चीजें हैं और उन लोगों के लिए एक पहचानकर्ता प्रदान किया जाना चाहिए जिन्हें संदर्भित करने की आवश्यकता है, लेकिन यह निर्धारित नहीं करता है कि, आपके ईआर मॉडल में संस्थाओं को आपके द्वारा बनाए गए URL के साथ 1-1 पत्राचार होना चाहिए (न तो यह है कि URLs को मॉडल में ER रिश्तों की कार्डिनैलिटी को एनकोड करना चाहिए)।

संपर्कों और पतों के मामले में, आप एक ऐसे संसाधन को परिभाषित कर सकते हैं जो संयुक्त रूप से इन सूचनाओं को एक इकाई के रूप में प्रस्तुत करता है, भले ही आप इन सूचनाओं को निकालने और सहेजना चाहें, कह सकते हैं, अलग-अलग संबंधपरक DB तालिकाओं, जब भी वे PUT या POSTed हैं। ।

Answer 3

Thats क्योंकि facades एक 'कीचड़' हैं; आपको i आपी एब्स्ट्रक्शन ’और cha एपी चैनिंग’ पर एक नजर डालनी चाहिए। एपीआई कार्यक्षमता के दो सेटों का एक संयोजन है: I / O और संसाधन प्रबंधन। स्थानीय रूप से, I / O ठीक है, लेकिन एक वितरित वास्तुकला (यानी प्रॉक्सी, एपीआई गेट, संदेश कतार, आदि) के भीतर I / O साझा किया जाता है और इस प्रकार डेटा और कार्यक्षमता डुप्लिकेट और उलझा हुआ हो जाता है। यह एक वास्तु-क्रॉस-कटिंग चिंताओं की ओर जाता है। यह सभी मौजूदा एपिस को प्रभावित करता है।

इसे हल करने का एकमात्र तरीका एपीआई के लिए I / O कार्यक्षमता को प्री / पोस्ट हैंडलर (जैसे स्प्रिंग / ग्रेल्स में हैंडलरइंटरसेप्ट या रेल में फिल्टर) को अमूर्त करना है, इसलिए कार्यक्षमता का उपयोग एक सनक के रूप में किया जा सकता है और उदाहरणों और बाहरी पर साझा किया जा सकता है टूलींग। अनुरोध / प्रतिक्रिया के लिए डेटा को भी एक वस्तु में बाहरी बनाना होगा ताकि इसे साझा किया जा सके और पुनः लोड किया जा सके।

http://www.slideshare.net/bobdobbes/api-abstraction-api-chaining

Answer 4

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

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

यह कला की स्थिति है, और व्यापक रूप से स्वीकार किया जाता है, कि यूआई कोड में किसी भी बिज़ लॉजिक को डालना एक बुरा विचार है। लेकिन हर यूआई केवल एक तरह का इंटरफ़ेस (यूआई में I) पीछे के तर्क को नियंत्रित करने के लिए है। नतीजतन, यह स्पष्ट प्रतीत होता है कि REST सेवा परत, या किसी भी अन्य API लेयर में किसी भी द्विज तर्क को रखना भी एक बुरा विचार है।

वैचारिक रूप से, यूआई और सेवा एपीआई के बीच इतना अंतर नहीं है।

Comments

मैं परत धारणा पर सहमत हूं, लेकिन "इसके माध्यम से अपने नियंत्रक प्रोग्राम" से आपका क्या मतलब है?

— एलेन

मैं इस तथ्य पर जोर देना चाहता हूं, कि नियंत्रक ही वास्तविक सेवा है। पूरी बात के आसपास लिपटे इंटरफ़ेस कुछ हासिल करने का एक साधन मात्र है। किसी भी तरह से या किसी अन्य में लिपटे कार्यक्षमता तक पहुंच को कम करने के लिए कोई भी इंटरफ़ेस मौजूद है। एक GUI मानव उपयोगकर्ताओं के लिए ऐसा करता है, एक सेवा एपीआई का उपयोग ग्राहकों द्वारा किया जाता है। दोनों लक्षित दर्शक इंटरफेस के पीछे लिपटे चीजों के साथ कुछ हासिल करना चाहते हैं। मैं मानता हूँ कि "कार्यक्रम" उस के लिए सबसे अच्छा शब्द नहीं हो सकता है, लेकिन "नियंत्रकों को नियंत्रित करना" या तो अजीब लगता है; ;-)

— जेन्स जी 30'13