2009-01-13 6 views
11

मैं एक वेब सेवा, या इंटरनेट पर उजागर कुछ अन्य सेवा डालने की योजना बना रहा हूं। मैं इस सेवा के साथ बातचीत करने के लिए अनुप्रयोगों के लिए एक एपीआई बनाना चाहता हूं। मैं एपीआई को जावा, सी ++, सी #, या PHP जैसी विभिन्न भाषाओं में उपयोग करने योग्य बनाना चाहता हूं। मैं अपने एपीआई के लिए एक कोड बेस कैसे बनाए रख सकता हूं, लेकिन इन सभी भाषाओं के लिए अच्छी पैकेज वाली बाइनरी वितरित कर सकता हूं? साथ ही, मैं यह विचार करना चाहूंगा कि यह क्रॉस प्लेटफॉर्म भी हो सकता है।भाषा अज्ञेय एपीआई

अद्यतन 1

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

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

अद्यतन 2

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

मेरा मूल विचार .NET में एक डीएलएल या असेंबली बनाना था, तो क्लाइंट क्लाइंट पक्ष चला रहे इस कोड में कॉल कर रहा है। यह कोड किसी भी संचार प्रोटोकॉल के माध्यम से सर्वर पर वापस बात कर सकता है, लेकिन मेरा एपीआई उनके बॉक्स पर चल रहा होगा। मुझे लगता है कि आरईएसटी वास्तव में इसे पूरा नहीं करता है। ऐसा लगता है कि आरईएसटी में सबकुछ अभी भी एक HTTP पोस्ट है। यह साबुन के साथ लगभग वेब सेवाएं है।

अद्यतन 3

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

सभी इनपुट के लिए धन्यवाद।

+0

इस प्रश्न को देखें: http://programmers.stackexchange.com/questions/157536/how-can-i-write-a-set-of-functions-that-can-be-invoked-from-almost-any -प्रोग्राम –

उत्तर

13

मैं एक REST API का, जिस तरह से फ़्लिकर के एपीआई काम करता है के लिए इसी तरह का प्रयोग करेंगे: http://flickr.com/services/api/

यह बना सकते हैं और बनाए रखने के लिए काफी सरल है, सबसे बड़ी कमियां है कि यह प्रलेखन का एक बहुत लेता है (लेकिन काफी किसी भी तरह आप एक एपीआई करेंगे इस मुद्दे में) और मजबूत त्रुटि हैंडलिंग एक जरूरी है।

लेकिन मेरी राय में, यह एक एपीआई कि है सबसे करीब मंच/पार भाषा पार करने के लिए बनाने के लिए सबसे अच्छा तरीका है।

अधिक यहाँ जानकारी: http://www.xfront.com/REST-Web-Services.html

अद्यतन: सबमिटर पोस्ट करने के लिए निम्नलिखित कहा:

मैं इसे बनाने एक सीधे वेब सेवा फिर एक WSDL फ़ाइल देने का विरोध नहीं कर रहा हूँ। लेकिन क्या होगा यदि मैं क्लाइंट एपीआई कुछ तर्क, एन्क्रिप्शन, त्रुटि जांच या ऐसा करने के लिए चाहता हूं?

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

सार्वजनिक एपीआई लिखा बाकी का उपयोग कर के कुछ और उदाहरण: twitter, vimeo, Google

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

अद्यतन 2: इस कोड में तो ग्राहक बना रही है कॉल कि चल रहा है

मेरे मूल विचार एक DLL या .NET में विधानसभा बनाने के लिए किया गया था: सबमिटर पद के लिए निम्न जोड़ा ग्राहक की ओर। यह कोड किसी भी संचार प्रोटोकॉल के माध्यम से सर्वर पर वापस बात कर सकता है, लेकिन मेरा एपीआई उनके बॉक्स पर चल रहा होगा। मुझे लगता है कि आरईएसटी वास्तव में इसे पूरा नहीं करता है। ऐसा लगता है कि आरईएसटी में सबकुछ अभी भी एक HTTP पोस्ट है। यह साबुन के साथ लगभग वेब सेवाएं है।

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

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

+0

मैंने आपके उत्तर का जवाब दिया। मुझे विचार पसंद है, लेकिन मैं उस चीज़ के बारे में सोच रहा था जिस पर मेरा अधिक नियंत्रण था। –

+0

कमाल। आपको अपनी प्रतिक्रिया के प्रति मेरी प्रतिक्रिया देखना चाहिए;) एचटीएच –

2

मैं वेब सेवाओं पर शुरुआती दिनों में हूं, लेकिन मुझे लगता है कि मुख्य बिंदुओं में से एक यह है कि बहुत सारे टूलिंग डब्लूडीएसएल जैसी सेवा के विवरण के आधार पर ग्राहकों के कार्यान्वयन का समर्थन करते हैं।

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

के रूप में अपने अन्य उत्तर में से एक ने सुझाव दिया कि आप Flickr API की जाँच करते हैं, तो मुझे नहीं लगता कि वे ग्राहक के पक्ष कोड की आपूर्ति, अन्य लोगों को बनाया गया है और ग्राहक के पक्ष सामान योगदान दिया है।

+0

मैंने आपके उत्तर का जवाब दिया। –

0

सरल उत्तर, नहीं।

जटिल उत्तर: एक एपीआई बनाएं और इसे COM dll पर संकलित करें। फिर, केवल उन भाषाओं के लिए रैपर कोड बनाएं जो इसे संभाल नहीं सकते हैं।

सरल उत्तर # 2, मूल सेवा को इतनी छोटी, या इतनी सार्वभौमिक स्वीकार्य बनाएं, क्योंकि एपीआई की आवश्यकता नहीं है (मैं आमतौर पर सर्वर-साइड डेटाबेस मतदान के माध्यम से इसे कार्यान्वित करता हूं। बदसूरत लेकिन डेटाबेस तक पहुंचने वाली कोई भी भाषा उपयोग कर सकती है कार्यक्रम)।

1

मैं सुझाव देता हूं कि एपीआई प्रोग्रामिंग भाषा में एपीआई लिखना ताकि स्रोत कोड का अनुवाद आपके द्वारा उल्लिखित सभी प्रोग्रामिंग भाषाओं में किया जा सके। हक्स प्रोग्रामिंग भाषा का अनुवाद मूल पोस्ट में उल्लिखित सभी प्रोग्रामिंग भाषाओं में (या "ट्रांस-संकलित") किया जा सकता है, साथ ही साथ कुछ अन्य।