वेब एपीआई के लिए कोई डब्ल्यूएसडीएल प्रकार का समर्थन क्यों नहीं है?

33

इसलिए मैं अभी .Net WebApi और एक बात से शुरुआत कर रहा हूं, जो कि मैं सीधे देख रहा हूं, यह है कि कोई भी अनुबंध यह परिभाषित नहीं करता है कि एपीआई कैसे दिखता है और इसका उपभोग किया जाना चाहिए (प्रत्येक क्रिया से अनुरोध / प्रतिक्रियाएं), यह आमतौर पर फॉर्म के रूप में होता है डब्ल्यूसीएफ / साबुन के लिए एक डब्ल्यूएसडीएल।

मुझे ऐसा लगता है कि यह कुछ ऐसा है जो बहुत मूल्यवान होगा और आपके एपीआई के उपभोक्ताओं के लिए जीवन को बहुत आसान बना देगा।

वहाँ एक कारण एक नहीं है? क्या कोई प्रोग्रामिंग प्रतिमान या सिद्धांत है जिससे मैं अनजान हूं? क्या कोई ऐसा तरीका है जिससे मैं एक बना सकता हूं?

c# asp.net-mvc web-api

— shenku
स्रोत

3

संबंधित: क्यों लोगों को लगता है कि SOAP हटा दिया गया है? । tl; dr: सोप और डब्लूएसडीएल तो 2007 हैं, और आरईएसटी वर्तमान में बम है।

— रॉबर्ट हार्वे

बहुत सारे स्थान जो कुछ व्यापक रूप से उपयोग किए जाने वाले एपीआई प्रदान करते हैं, आमतौर पर विभिन्न भाषाओं के लिए पुस्तकालय होते हैं जिनका उपयोग आप उनके एपीआई का उपभोग करने के लिए कर सकते हैं। उन स्थानों के लिए जो एक प्रदान नहीं करते हैं, आमतौर पर इसके लिए एक खुला स्रोत परियोजना है। उदाहरण के लिए, सी # के लिए ट्विलियो यहां, github.com/twilio/twilio-csharp ।

— पीट

1

@RobertHarvey: SOAP को इतना बदनाम नहीं किया गया है क्योंकि इसे बदनाम किया गया है : इसे आधिकारिक तौर पर अनुशंसित करने की आवश्यकता नहीं है कि जिसने भी इसके खिलाफ सिफारिश करने के लिए पता करने के लिए इसे बनाया है।

— मेसन व्हीलर

stackoverflow.com/a/32744753/794606

— Jacek Cz

23

सोप, बाकी और लोगों की रचनात्मकता

एसओएपी को डब्ल्यूएसडीएल जैसे विवरण दस्तावेज की आवश्यकता होती है क्योंकि प्रत्येक संसाधन को विभिन्न संदेशों के साथ खाया जा सकता है, संभव नाम / संदेशों के लिए बाधाओं के बारे में प्रोटोकॉल पर कोई परिभाषा नहीं है कि आप किसी संसाधन में हेरफेर कर सकते हैं।

उदाहरण के लिए, SOAP में आपकी वेब सेवा जो ग्राहकों को एक उपयोगकर्ता को हेरफेर करने की अनुमति देती है, उस ऑपरेशन को उजागर कर सकती है जो उपयोगकर्ता को कई अलग-अलग संदेशों में बनाता है, जैसे:

addUser
createUser
insertUser

बेशक, ये केवल कुछ नमूना संदेश हैं, क्योंकि मैंने बहुत सारी अजीब वेब सेवाओं के नाम देखे हैं। वहाँ वास्तव में रचनात्मक लोग हैं।

दूसरी ओर, यदि आप वेब एप का उपयोग करके अपने अंतर्निहित सिस्टम को उजागर कर रहे हैं जो वास्तव में REST सिद्धांतों का सम्मान करते हैं, तो क्लाइंट को केवल यह जानना होगा कि आपके पास उपयोगकर्ता नाम का एक संसाधन है, क्योंकि 99% संभावना है कि आप इसमें उपयोगकर्ता बना सकते हैं मार्ग

POST /Users

और यह प्रत्येक ऑपरेशन के लिए होता है जिसे आप एसओएपी या वेब एप रीस्ट का उपयोग करके उजागर करना चाहते हैं।

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

एक वेब एपीआई परीक्षा की स्थापना

वेब एप रीस्ट का वर्णन करने के क्षेत्र में मैं स्वैगर का हवाला दे सकता हूं । यह वेब एपीआई रीस्ट की तरह एक डब्ल्यूएसडीएल बनाने का प्रयास नहीं है, लेकिन वेब एप रीस्ट का वर्णन करने के लिए एक खुला मानक बनाने का यह एक अच्छा प्रयास है।

स्वैगर रेस्टफुल वेब सेवाओं का वर्णन, निर्माण, उपभोग और कल्पना करने के लिए एक विनिर्देश और पूर्ण रूपरेखा कार्यान्वयन है।

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

अधिकांश भाषाओं के लिए स्वैगर के कई कार्यान्वयन हैं: सी #, जावा, पायथन, रूबी, आदि।

यदि आप ASP .NET वेब API का उपयोग कर रहे हैं, तो Swagger.NET की तरह स्वैगर विनिर्देश उत्पन्न करने के लिए कुछ प्रोजेक्ट्स ऑटो हैं

एक वेब एपीआई परीक्षा में उत्पन्न करने वाले ग्राहक

क्योंकि REST की बाध्यता, क्रियाओं के सीमित सेट (GET, POST, PUT, DELETE, आदि) की तरह एक वेब एप रीस्ट के लिए क्लाइंट लाइब्रेरी उत्पन्न करने के लिए इतनी भिन्न नहीं है।

WebApiProxy जैसी परियोजनाएं आसानी से ग्राहकों को C # और जावास्क्रिप्ट उत्पन्न कर सकती हैं।

वेब एपीआई परीक्षा के लिए विचार

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

— giacomelli
स्रोत

कृपया WADL को शामिल करें, मैं इसकी पूरी तरह से पुष्टि करता हूं कि हमें RESTfull / JSON एपि के उद्यम को निर्दिष्ट करने की आवश्यकता है .... जबकि अभी भी WSDL की तुलना में अधिक उचित है। स्वैगर उपभोग करने के लिए महान है, से एक कंकाल उत्पन्न करने के लिए, लेकिन यह मेरे दिमाग में निचले स्तर पर बैठता है। WADL -> स्वैगर -> कोड कंकाल। WADL मौजूदा इको-सिस्टम में भी फिट बैठता है और उद्यम डेवलपर्स के लिए यह आवश्यक है।

— जेएम बेकर

3

मैं ... वास्तव में एक छोटा सा गूंगा हूँ। बाकी GETके लोग अधिक सीधे हैं, हाँ। लेकिन, यह जानकर क्या क्रियाएं कर रहे हैं शायद समर्थित मतलब यह नहीं है कि आप एक एपीआई के साथ बातचीत कर सकते हैं सब पर । हमारे पास अभी भी कोई स्कीमा या डोमेन ज्ञान नहीं है। असली जवाब है, अगर हम ईमानदार जा रहा है कर रहे हैं, कि हमारी सेवा में परिवर्तन नहीं है स्पष्ट रूप से एकीकरण के साथ अनुबंध तोड़ने जब वहाँ कोई अनुबंध (WSDL) को तोड़ने के लिए है। और, वेब पर, हम चाहते हैं कि स्वतंत्रता को विली-नीली, अपराध-मुक्त और व्हाट्सएप को बदलने की स्वतंत्रता हो। लेकिन, हमें एपीआई डॉक्स पढ़ने और * वैसे भी प्रयोग करने की आवश्यकता है ... तो, हम उस के साथ ज्यादातर ठीक हो गए हैं ...

— svidgen

5

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

इसके अलावा, SOAP (WS- * विनिर्देशों) के लिए कई एक्सटेंशन हैं जो एन्क्रिप्शन या लेनदेन व्यवहार को SOAP के साथ उपयोग करने की अनुमति देते हैं। विचार यह है कि आप एंटरप्राइज़-ग्रेड webservices बनाने के लिए SOAP का उपयोग अपनी वन-स्टॉप शॉप के रूप में कर सकते हैं।

दूसरी ओर...

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

संक्षेप में, आप कह सकते हैं कि SOAP webservices का उपयोग आम तौर पर (संभवत: असमान) समाधानों को एकीकृत करने के लिए किया जाता है, जबकि REST सेवाएँ समान समाधान के कुछ हिस्सों के बीच संचार प्रदान करने के लिए बेहतर अनुकूल होती हैं।

— Astrotrain
स्रोत

1

SOAP / WS- * और RESTful API समान नहीं हैं। यदि आप SOAP / WS- * WSDL का समर्थन करना चाहते हैं, तो Microsoft स्टैक में पसंद का टूल WCF है, जो HTTP बाइंडिंग ऑप्शन के साथ माउंट किया गया है (XML और JSON बाइंडिंग विकल्प हैं, XML WSDL सपोर्टिंग ऑप्शन है)।

व्यवहार में, एक अलग कार्यान्वयन भाषा या मंच से एक WSDL का उपभोग करना समस्याग्रस्त रहा है। WS- * शीर्ष पर सुरक्षा परतें और भी अधिक।

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

ये कुछ कारण हैं जिनके कारण लोग सरल कार्यान्वयन की कोशिश करते दिखे। अन्य सेवाएं (ala Web API) ऑब्जेक्ट / स्थिति के आसपास समापन बिंदु प्रदान करती हैं। JSON प्रारूप में प्रतिनिधित्व सरल ऑब्जेक्ट संरचनाओं के एक सेट को परिभाषित करना आसान है, और इन संरचनाओं के खिलाफ उपयोग करने के लिए समापन बिंदु यह है कि किसी विदेशी वातावरण से WSDL का उपयोग करने की कोशिश न करें, जो फिर काम नहीं करता है समस्या के आसपास काम करें।

विडंबना यह है कि इस क्षेत्रों मैं एक में नोड का उपयोग किया है में से एक है बहुत एक अनुवाद सेवा के रूप में बस, क्योंकि यह लचीला एक ग्राहक के रूप में गंदा कार्यान्वयन को स्वीकार करने के लिए पर्याप्त था, और मैं अपने अनुकूलित पेलोड कि बेहतर काम किया के खिलाफ सरल ग्राहकों लिख सकता है,। EX: C # को JSON टेक्स्ट मिलता है, जिसे मैं JSON.Net का उपयोग एक ऑब्जेक्ट प्रतिनिधित्व में बदलने के लिए करता हूं, जिसे मैंने वास्तव में परिभाषित किया था जब मैं एक WSDL आयात का उपयोग नहीं कर सकता था।

व्यवहार में यह बहुत कुछ होता है।

— Tracker1
स्रोत

-3

हालांकि यहां बहुत सारे उत्तर महान हैं, मुझे लगता है कि उत्तर बहुत सरल है: आप नौकरी के लिए गलत तकनीक देख रहे हैं।

यदि आप SOAP- सेवा का निर्माण करना चाहते हैं, तो आपको वास्तव में WCF से चिपके रहना चाहिए। यह अभी भी एक बहुत शक्तिशाली ढांचा है, माइक्रोसॉफ्ट अभी भी इसे सक्रिय रूप से विकसित कर रहा है, भविष्य में कहीं भी यह सोचने के लिए हमारे लिए कोई घोषणा नहीं की गई थी, और यह इसे ध्यान में रखकर बनाया गया था। वेब एपीआई किसी भी तरह से WCF को सुपरसीड नहीं करता (हालाँकि यह शायद WCF से ज्यादा ट्रेंडियर है)।

वेब एपीआई WCF का हिस्सा हुआ करता था, लेकिन इसे ASP.NET परिवार में स्थानांतरित कर दिया गया था, लेकिन वास्तव में यह अन्य WCF प्रौद्योगिकियों के साथ फिट नहीं था। वेब एपीआई एक ट्रांसफर प्रोटोकॉल की तुलना में एचटीटीपी को एक एप्लिकेशन प्रोटोकॉल के रूप में उपयोग करने से बहुत अधिक चिंतित है। वेब एपीआई में, HTTP क्रियाएं राजा हैं, WCF HTTP में केवल SOAP प्रोटोकॉल को सक्षम करने के लिए कार्य करता है।

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

— romatthe
स्रोत

3

इस सवाल का जवाब नहीं है।

— एंडी