रीस्टफुल एपीआई: मुझे अपना वर्कफ़्लो कहां कोड करना चाहिए?

Question

मैं एक विश्वसनीय API विकसित कर रहा हूं। यह मेरा पहला एपीआई है, लेकिन मेरा पहला वास्तव में बड़ा कोडिंग प्रोजेक्ट भी है। जैसे, मैं अभी भी वास्तुकला के बारे में बहुत सीख रहा हूँ आदि

वर्तमान में, मैं निम्नलिखित परतों में मेरी एपीआई सेटअप:

• HTTP परत
• संसाधन लेयर
• डोमेन मॉडल/व्यापार तर्क परत
• डेटा एक्सेस/भंडार लेयर
• स्थायी संग्रहण/डीबी लेयर

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

वर्तमान में, मेरी कार्यप्रवाह तर्क संसाधन परत में है। मैं उपयोगकर्ता को वर्कफ़्लो प्रस्तुत करने के लिए हाइपर्मियाडिया लिंक का उपयोग कर रहा हूं उदा। एक 'अगला कदम' लिंक प्रदान करना। मेरे पास समस्या यह है कि संसाधन परत एक शीर्ष स्तर की परत है, और प्रस्तुति के साथ अधिक गठबंधन है। मैं यह अंतर्निहित डोमेन मॉडल को प्रभावी ढंग से एक कार्यप्रवाह यानी यह पता करने के लिए यह भुगतान अनुमति देने से पहले personal_detail रों इकाई की जाँच करने के है की आवश्यकता होगी का मूल्यांकन करने के बारे में जानने की बहुत अधिक जरूरत महसूस करते हैं।

यह अब मुझे यह सोच कर कि वर्कफ़्लो डोमेन मॉडल से संबंधित होता है। यह बहुत अधिक समझ में आता है, क्योंकि वास्तव में वर्कफ़्लो व्यवसाय तर्क का हिस्सा हैं और मुझे लगता है कि डोमेन परत में सबसे अच्छा रखा गया है। आखिरकार, किसी अन्य चीज़ के साथ संसाधन परत को प्रतिस्थापित करें, और आपको अभी भी अंतर्निहित वर्कफ़्लो की आवश्यकता होगी।

लेकिन अब समस्या यह है कि कई डोमेन वस्तुओं के आवश्यक ज्ञान कार्यप्रवाह उनके तर्क को पूरा करने के लिए है। अब यह सही लगता है कि यह शायद अपनी परत में चला जाता है? संसाधन और डोमेन परत के बीच?

• HTTP परत
• संसाधन लेयर
• कार्यप्रवाह लेयर
• डोमेन मॉडल/व्यापार तर्क परत
• डेटा एक्सेस/भंडार लेयर
• स्थायी संग्रहण/डीबी लेयर

मैं बस सोच रहा हूं कि क्या किसी के पास इस के आसपास कोई अन्य विचार या विचार था? जैसा कि मैंने कहा, मेरे पास यह जानने के लिए कोई पिछला अनुप्रयोग अनुभव नहीं है कि वर्कफ़्लो कहां रखा जाना चाहिए। मैं वास्तव में पहली बार यह सीख रहा हूं इसलिए यह सुनिश्चित करना चाहता हूं कि मैं इसके बारे में सही तरीके से जा रहा हूं। लेख या ब्लॉग पर

लिंक है कि इस कवर बहुत सराहना की जाएगी। विभिन्न कार्यान्वयन पर पढ़ने के लिए प्यार।

संपादित

स्पष्ट करने के लिए, मैं रिलीज कि HATEOAS ग्राहक 'कार्यप्रवाह' के माध्यम से नेविगेट करने के लिए अनुमति देता है, लेकिन वहाँ मेरी एपीआई में कुछ ऐसा है जो जानता है कि यह यानी दिखाने के लिए लिंक वास्तव में कार्यप्रवाह है कि परिभाषित करने है क्या होना चाहिए की अनुमति दी। यह संसाधन में वर्कफ़्लो संबंधित लिंक प्रस्तुत करता है, लेकिन इसके अतिरिक्त यह सत्यापित करता है कि अनुरोध वर्कफ़्लो के साथ समन्वयित हैं। जबकि मैं मानता हूँ कि एक ग्राहक शायद ही संसाधन, बाकी के खतरे (और सुंदरता) में दिए गए लिंक का पालन करेंगे, कि अपनी यूआरआई संचालित है, तो एक शरारती 'छोड़' के लिए द्वारा कार्यप्रवाह में कदम की कोशिश कर ग्राहक को रोकने के कोई बात नहीं है यूआरआई में एक शिक्षित अनुमान बनाते हुए। एपीआई को यह पता लगाने और 302 प्रतिक्रिया वापस करने की जरूरत है।

Answer 1

इस प्रश्न का उत्तर मुझे थोड़ा सा शोध ले गया है, लेकिन मूल रूप से 'वर्कफ़्लो' भाग में आरईएसटी के साथ कुछ भी नहीं है और आवेदन परत के साथ बहुत कुछ करना है।

मेरे प्रणाली आवेदन तर्क और REST API का बहुत कसकर युग्मित था। मैंने युग्मन को कम करने के लिए रिफैक्टरिंग करके अपनी समस्या हल की और अब वर्कफ़्लो एप्लिकेशन के संदर्भ में रहता है

Answer 2

बाकी क्रियाओं का एक स्थापित सेट (मिलता है, पोस्ट, PUT, DELETE) के खिलाफ संज्ञाओं (उपयोगकर्ताओं, उत्पादों, शॉपिंग कार्ट) की शब्दावली बनाने के लिए प्रोत्साहित करती है। यदि आप इस नियम से चिपके रहते हैं, तो आपके उदाहरण में वर्कफ़्लो वास्तव में उपयोगकर्ता द्वारा आपकी साइट के साथ इंटरैक्शन के सेट द्वारा परिभाषित किया जाता है। इस प्रकार उपयोगकर्ता आपके ऐप का उपयोग करता है, जिसे वास्तव में यूआई द्वारा परिभाषित किया जाता है। आपकी आरईएसटी सेवाओं को अमान्य राज्य अनुरोधों के लिए उचित प्रतिक्रिया देनी चाहिए, जैसे रिक्त कार्ट के साथ चेकआउट करने का प्रयास करना, लेकिन यूआई स्क्रिप्ट का उपयोग करके ऐसे अनुरोधों को भी रोक सकता है, जो आरईएसटी की एक वैकल्पिक विशेषता है।

उदाहरण के लिए, यूआई जो उपयोगकर्ता को उत्पाद प्रदर्शित करता है वह एक लिंक भी प्रदर्शित कर सकता है जो उपयोगकर्ता को उस उत्पाद को अपने कार्ट (पोस्ट शॉपिंगकार्ट/{productId}) में जोड़ने की अनुमति देगा। सर्वर को वास्तव में परवाह नहीं करना चाहिए कि उपयोगकर्ता को उस पोस्ट को कैसे मिला, केवल यह कि उस उत्पाद को उपयोगकर्ता के कार्ट में जोड़ना चाहिए और उपयोगकर्ता को कार्ट का अद्यतन प्रस्तुतिकरण वापस करना चाहिए। यूआई तब जावास्क्रिप्ट का उपयोग यह निर्धारित करने के लिए कर सकता है कि चेकआउट के लिए केवल एक लिंक प्रदर्शित करना है या नहीं, अगर शॉपिंग कार्ट में एक या अधिक आइटम हैं।

तो ऐसा लगता है कि अपने कार्यप्रवाह बाकी सेवा के बाहर रहता है और नहीं बल्कि अपने पृष्ठों, जो आपके बाकी सेवाओं के साथ सहभागिता के रूप में उपयोगकर्ता बातों का अनुरोध करता है में नेविगेशन द्वारा परिभाषित किया गया है। यह निश्चित रूप से संभव है कि आपके पास आंतरिक वर्कफ़्लो हो जो आपके आवेदन के भीतर उपयोगकर्ता द्वारा स्थापित राज्यों के आधार पर हो। लेकिन आप जो वर्णन कर रहे हैं वह साइट के भीतर एक उपयोगकर्ता इंटरैक्शन है, और यह वास्तव में वर्कफ़्लो है, लेकिन यह आपके यूआई द्वारा समर्पित सर्वर-साइड घटक/परत की तुलना में बेहतर परिभाषित करता है।

Answer 3

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

Answer 4

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

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

तो, अगर वहाँ सर्वर पर सत्र स्थिति है, यह आराम नहीं है।

अपने शॉपिंग कार्ट उदाहरण के लिए, आप रेडिस जैसी अलग कैशिंग परत में राज्य को बचा सकते हैं।आपके वर्कफ़्लो के लिए। आप व्यवसाय तर्क को अपने शॉपिंग कार्ट या डोमेन मॉडल में कुल बिल की गणना करना नहीं चाहते हैं। वह सेवा परत में जोड़ा जाएगा।

आपने यूआरएल अनुमान लगाने वाले शरारती उपयोगकर्ताओं के बारे में बात की। यह हमेशा एक चिंता है और आपकी सुरक्षा द्वारा संभाला जाना चाहिए। यदि उपयोगकर्ता को हटाने के लिए यूआरएल DELETE/user/3782 है ... वे आसानी से अनुमान लगा सकते हैं कि सभी उपयोगकर्ताओं को कैसे हटाया जाए। लेकिन आपको केवल यूआरएल को खराब करने पर भरोसा नहीं करना चाहिए। यदि आपके अनुरोध मान्य हैं तो आपके पास अंतिम अंतराल के अंदर वास्तविक सुरक्षा और पहुंच जांच होनी चाहिए।

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