वेब सेवा विकसित करने के लिए कोई समस्या/सुझाव क्या हो सकता है

Question

ग्राहकों को हमारे प्लेटफ़ॉर्म के साथ एकीकृत करने का एक आसान तरीका प्रदान करने के लिए PHP में एक वेब सेवा (एपीआई) विकसित करना चाहते हैं। वर्कफ़्लो कॉल हैं जिन्हें उपयोगकर्ता/पास के साथ-साथ कुछ रिपोर्टिंग विकल्पों के साथ भी सत्यापित किया जाएगा।

क्षमा करें मैं इस विषय पर अधिक जानकारी या कोड पोस्ट नहीं कर सकता हूं और मैंने कभी भी वेब सेवा विकसित नहीं की है लेकिन SOAP के माध्यम से उनका उपयोग करने में अनुभव किया है।

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

रिपोर्टिंग के लिए मैं एक्सएमएल, एक्सेल/सीएसवी जैसे विभिन्न विकल्पों की पेशकश करना चाहूंगा, किसी भी कारण से मैं एक दूसरे को चुनूँगा?

मुझे कुछ परेशानियों के बारे में क्या पता होना चाहिए?

कोई भी रत्न जो पेशकश कर सकता है।

किसी भी मदद के लिए अग्रिम धन्यवाद क्योंकि मेरे लिए यह समझना बहुत महत्वपूर्ण है।

अद्यतन # 1:

• क्या सबसे सुरक्षित तरीका होगा?
• क्या सबसे लचीला विधि (मंच स्वतंत्र)

अद्यतन # 2: डाटा प्रवाह के बारे में थोड़ा। प्रत्येक उपयोगकर्ता के पास API का उपयोग करने के लिए क्रेडिट है और उपयोगकर्ताओं के बीच कोई डेटा साझा नहीं किया जाता है। उपयोग एक अनुरोध जमा है, अनुरोध संसाधित किया गया है और एक वापसी दी गई है। कोई अपडेट नहीं (Google को सोचें) एक खोज अनुरोध किया गया है और परिणाम दिए गए हैं, लेकिन मेरे मामले में केवल एक परिणाम दिया गया है। पता नहीं है कि इसकी आवश्यकता है तो यह एक एफवाईआई है।

Answer 1

Always handle errors and exceptions. 

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

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

Answer 2

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

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

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

Answer 3

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

अनिवार्य रूप से एसओए का अर्थ है व्यावसायिक प्रक्रियाओं के आसपास वेब सेवा डिज़ाइन करना, यानी आपके एपीआई का उपयोग करने वाले लोग इसका उपयोग कैसे कर सकते हैं।

एक अच्छी desgin हमेशा एक अच्छा विचार है, इसलिए मैं अत्यधिक अनुशंसा करता हूं कि आप कोडिंग शुरू करने से पहले वेब सेविस डिजाइन सिद्धांतों पर बहुत कुछ पढ़ लें और बाद में दुःख के कुछ अन्य दुर्भाग्यपूर्ण सॉड को बचाएं।

यह भी सुनिश्चित करें कि आपका डिज़ाइन चुस्त है क्योंकि यह आपकी कंपनी और आपके ग्राहकों के बीच संचार के रूप में अक्सर बदल जाएगा।

Answer 4

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

Answer 5

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

किसी भी चीज की सुरक्षा पक्ष पर जो किसी भी इनपुट को गतिशील रूप से संसाधित करता है, किसी को ऐसे इनपुट का इलाज करना चाहिए जैसे आप छड़ी के साथ भी नहीं दबाएंगे।

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

मैं आपको एक गहरी सांस लेने के लिए धन्यवाद देता हूं, एक पेंसिल & एक पेपर, बैठे और सब कुछ आवश्यक होने के लिए स्केच करें। फिर आप कम महत्वपूर्ण चीजें हटाते हैं, और एक नया पेपर लेते हैं और इसे व्यवस्थित करना शुरू करते हैं। आप API के अगले संस्करण में कम महत्वपूर्ण सामग्री जोड़ सकते हैं।

एपीआई को डिज़ाइन करने का प्रयास करें ताकि आप स्वयं को कोने में लॉक न करें, इस पर कोई धारणा न करें कि यह कहां जा रहा है।