WCF डेटा सेवाएँ (OData) बनाम ASP.NET वेब API

Question

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

मैंने प्रत्येक के बारे में कुछ प्रस्तुतियों को ऑनलाइन देखा है और अभी मैं मुख्य रूप से WCF डेटा सेवाओं की ओर झुकाव कर रहा हूं क्योंकि URI और देशी हाइपरमीडिया क्षमता में निर्मित फ़िल्टरिंग तंत्र। एकमात्र नकारात्मक पहलू जो मैं देख सकता हूं वह है एटम पब विनिर्देश की क्रियाशीलता जैसा कि पीओएक्स के विपरीत।

क्या निर्णय लेने से पहले मुझे इन दोनों तकनीकों के बारे में कुछ पता होना चाहिए? WCF डेटा सेवाओं पर ASP.NET वेब एपीआई का चयन कोई क्यों करेगा?

Answer 1

यह एक व्यक्तिपरक प्रश्न है, इसलिए यहाँ एक व्यक्तिपरक उत्तर है। IMO, WCF के पास सरल रेस्टफुल सेवाओं के लिए बहुत अधिक ओवरहेड है। दूसरी ओर, वेब एपीआई को विशेष रूप से रेस्टफुल सेवाओं के लिए डिज़ाइन किया गया था।

मैं इस पर डेव वार्ड के साथ समझौता कर रहा हूं । अधिक जानकारी के लिए उनके ब्लॉग को देखें।

मैं WebForms परियोजनाओं में ASMX से WCF में जाने के लिए दबाव के खिलाफ लंबे समय से आयोजित हूं, क्योंकि WCF की जटिलता को स्वीकार करते हुए मुख्य रूप से मुझे केवल कम लचीले JSON क्रमांकन के साथ पुरस्कृत किया गया था। इसके विपरीत, मैंने ASMX से अपनी कुछ परियोजनाओं को वेब एपीआई में परिवर्तित करना शुरू कर दिया है, और इस बात से प्रसन्न हो गया है कि वेब एपीआई एमएमएक्स को कितनी आसानी से बदल देता है।

मेरा मानना ​​है कि माइक्रोसॉफ्ट ने आखिरकार एएसएमएक्स की सादगी और वेब एपीआई के साथ डब्ल्यूसीएफ की शक्ति के बीच एक अच्छा संतुलन पाया है।

Comments

जवाब के लिए धन्यवाद! मेरे पास एक अनुवर्ती प्रश्न है, इसलिए मुझे आशा है कि आप ASP.NET वेब एपीआई से काफी परिचित हैं। WCF Data Services के बारे में एक बात मुझे बहुत अच्छी लगी। उनके नेटफ्लिक्स उदाहरण का उपयोग करके, आप फिल्मों की एक शैली को क्वेरी कर सकते हैं और बॉक्स से बाहर सेवा प्रत्येक फिल्म के लिए पूरी प्रविष्टि के बजाय उस शैली में प्रत्येक फिल्म के लिंक लौटाएगी। वहाँ ASP.NET वेब एपीआई के साथ ऐसा करने का एक तरीका है? ऐसा लगता है कि यह हाइपरमीडिया का उपयोग करने के बजाय आपको पूरी विस्तारित वस्तु संरचना प्रदान करता है।

— रेमंड सॉल्टरी

मुझे अभी तक इसका उपयोग करने का मौका नहीं मिला है, लेकिन ऐसा लगता है कि आप MediaTypeFormatterअपनी प्रतिक्रियाओं को प्रारूपित करने के लिए लागू कर सकते हैं । एक नमूना के लिए code.msdn.microsoft.com/Contact-Manager-Web-API-0e8e373d देखें ।

— 21

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

— रेमंड साल्ट्रेली

मुझे लगता है कि इस उत्तर की फिर से समीक्षा होनी चाहिए क्योंकि Microsoft वेब एप पर ओवरडेट वेब एपीआई का उपयोग करने पर जोर दे रहा है।

— codebased

Answer 2

वर्तमान में WebApi और WCF डेटा सेवाओं के बीच अन्य प्रमुख अंतर हैं, जिनका कोई भी उल्लेख नहीं करता है। काश एमएस एक अच्छे लेख के साथ दोनों की तुलना करता।

मैं थोड़ी देर के लिए और वेबएपीआई के बाद भी ओडता का पालन कर रहा हूं। मैंने हमेशा कुछ प्रमुख भेद पाए हैं।

पहले, मुझे यकीन नहीं है कि आपके बॉस का अर्थ है "एमएस वेबएपी का समर्थन कर रहा है", इसका मतलब है कि वे ओडिटा का समर्थन नहीं कर रहे हैं ?? IMO, वे दोनों का समर्थन कर रहे हैं और वर्तमान में कुछ न्यूनतम ओवरलैप है। Windows Azure Data Market, OData का उपयोग करके अपने डेटा को उजागर करता है, Azure टेबल स्टोरेज OData का उपयोग करता है, SharePoint 2010 डेटा पर ओवरडेट क्वेरीज़ की अनुमति देता है, और MS से अन्य उत्पाद भी इसका समर्थन कर रहे हैं, जैसे Excel PowerPivot। जब यह रिलेशनल डेटा की बात आती है तो यह एक बहुत शक्तिशाली क्वेरी फ्रेमवर्क है। और क्योंकि यह RESTful है, कोई भी भाषा, ढांचा, उपकरण, आदि इसके साथ एकीकृत कर सकते हैं।

यहाँ मुझे ओडटा + डब्ल्यूसीएफ डेटा सेवाओं के बारे में क्या पसंद है:

OData + WCF डेटा सेवाओं ने अंततः वेब पर डेटा की क्वेरी करते समय क्लाइंट एप्लिकेशन को अधिक "अभिव्यंजक" होने की अनुमति दी है। इससे पहले, हमें हमेशा कठोर वेब APIs के निर्माण के लिए ASMX या WCF का उपयोग करना पड़ता था, जो अनजाने में हो जाते हैं और जब भी UI कुछ अलग करना चाहता है तो उसे निरंतर परिवर्तनों की आवश्यकता होती है। क्लाइंट अनुप्रयोग केवल मापदंडों को निर्दिष्ट कर सकता है कि कौन से मापदंड को वापस करना है। या जैसे मैंने किया था और LINQ एक्सप्रेशंस को "सीरियलाइज़" करें और उन्हें पैरामीटर्स के रूप में पास करें और Expressions<Func<T,bool>>सर्वर पर फिर से हाइड करें । इसका सभ्य है। काम मिल गया है, लेकिन मैं क्लाइंट पर LINQ का उपयोग करना चाहता हूं और इसे REST का उपयोग करके वेब पर अनुवादित किया है, जो कि ओडटा अनुमति देता है और मैं समाधान के अपने "हैक" का उपयोग नहीं करना चाहता।

यह एक DB कनेक्शन स्ट्रिंग की आवश्यकता के बिना "ट्रांसपोर्ट एसक्यूएल" को उजागर करने जैसा है। बस एक Url और whoala प्रदान करें! क्वेरी करना प्रारंभ करें। बेशक, वेबएपीआई और डब्ल्यूसीएफ डेटा सेवा दोनों प्रमाणीकरण / प्राधिकरण का समर्थन करते हैं, इसलिए आप पहुंच को नियंत्रित कर सकते हैं, भूमिकाओं या अन्य डेटा कॉन्फ़िगरेशन के आधार पर अतिरिक्त "कहां" बयान जोड़ सकते हैं। मैं इसे SQL की तुलना में अपने वेब एपी लेयर में करना चाहूंगा (जैसे कि व्यू या स्टोर किए गए प्रॉक् स का निर्माण)। और अब जब एप्लिकेशन स्वयं ही प्रश्नों का निर्माण कर सकते हैं, तो आप विज्ञापन-हॉक और बीआई रिपोर्टिंग उपकरण देखेंगे जो ओडटा का लाभ उठाना शुरू कर देंगे और उपयोगकर्ताओं को अपने स्वयं के परिणामों को परिभाषित करने की अनुमति देंगे। स्टेटिक रिपोर्ट्स पर भरोसा न करना जहां उनका न्यूनतम नियंत्रण है।

सिल्वरलाइट, विंडोज 8 मेट्रो, या ASP.NET (MVC, WebForms, आदि) में विकसित होने पर, आप केवल WCF डेटा सेवा के लिए Visual Studio में "सेवा संदर्भ" जोड़ सकते हैं और डेटा को क्वेरी करने के लिए LINQ का उपयोग करना शुरू कर सकते हैं और आपको एक अरबी मिल जाएगी क्लाइंट पर "डेटा संदर्भ", जिसका अर्थ है कि यह परिवर्तनों को ट्रैक करता है और आपको अपने परिवर्तनों को सर्वर पर वापस "सबमिट" करने की अनुमति देता है। यह सिल्वरलाइट के लिए आरआईए सर्विसेज के लिए बहुत उपयोगी है। मैंने RIA सेवाओं के बजाय WCF डेटा सेवाओं का उपयोग किया होगा, लेकिन उस समय, यह DataAnnotations या Actions का समर्थन नहीं करता था, लेकिन अब यह करता है :) RC सेवाओं पर WCF डेटा सेवाओं का एक और लाभ है, जो कि "अनुमान" करने की क्षमता है क्लाइंट से। यह प्रदर्शन के साथ मदद कर सकता है, मुझे लगता है कि मैं सभी संपत्तियों को एक इकाई से वापस नहीं करना चाहता। "डेटा संदर्भ" होने से

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

WCF डेटा सेवाओं के लिए नकारात्मक पक्ष "नियंत्रण" है जो आप HTTP स्टैक पर ढीला करते हैं। मैंने पाया कि सबसे बड़ा दोष उन IQueryable<T>तरीकों में था जो कलेक्शन लौटाते हैं। आरआईए सेवाओं और वेबएपीआई के विपरीत, आपके पास IQueryable विधि में तर्क विकसित करने के लिए पूर्ण पहुंच नहीं है। RIA Services और WebApi में, जब तक आप वापस आते हैं, तब तक आप जो चाहें कोड लिख सकते हैं IQueryable<T>। WCF डेटा सेवाओं में, आपको केवल Expression<Func<T,bool>>इंटरसेप्टर विधियों का उपयोग करके "कहां" स्टेटमेंट को जोड़ने की सुविधा मिलती है । मुझे यह निराशाजनक लगा। हमारा वर्तमान एप्लिकेशन RIA सेवाओं का उपयोग करता है और मुझे लगता है कि हमें वास्तव में IQueryable लॉजिक को नियंत्रित करने की क्षमता की आवश्यकता है। मुझे उम्मीद है कि मैं इस पर गलत हूं और मुझे कुछ याद आ रहा है

इसके अलावा, WCF डेटा सेवाएँ अभी भी पूरी तरह से सभी LINQ ऑपरेटर्स का समर्थन नहीं करती हैं। यह अभी भी WebApi से अधिक का समर्थन करता है।

WebApi के बारे में क्या ???

1. मुझे Http Request / Response पर नियंत्रण पसंद है
2. इसका पालन करना आसान है (एमवीसी पैटर्न का लाभ उठाते हुए)। मुझे यकीन है कि अधिक टूलींग आ जाएगा।

अब तक (मेरी समझ में), क्लाइंट (यानी सिल्वरलाइट, ASP.NET सर्वर-साइड कोड, आदि) पर कोई "डेटा संदर्भ" समर्थन नहीं है, क्योंकि WebApi वास्तव में WCF डेटा सेवाओं / OData जैसे इकाई डेटा मॉडल के बारे में नहीं है है। यह IQueryable / IEnumerable का उपयोग करके मॉडल ऑब्जेक्ट के संग्रह को बेनकाब कर सकता है, लेकिन क्लाइंट पर एक बार एंटिटी लोड होने के बाद कोई प्राथमिक कुंजी / विदेशी कुंजी "नेविगेशन गुण" (यानी ग्राहक। इनवॉइस) का उपयोग करने के लिए नहीं है, क्योंकि कोई "डेटा संदर्भ" नहीं है। जो उन्हें अतुल्यकालिक रूप से लोड करता है (या $ का उपयोग करके एक कॉल में), और परिवर्तनों का प्रबंधन करता है। आपके पास क्लाइंट पर आपके इकाई डेटा मॉडल का कोई कोड-जनरेट किया गया "प्रतिनिधित्व" नहीं है, जैसे आप आरआईए सेवाओं या डब्ल्यूसीएफ डेटा सेवाओं में करते हैं। मैं यह नहीं कह रहा / सकती कि आपके डेटा का प्रतिनिधित्व करने वाले क्लाइंट में मॉडल नहीं हैं, लेकिन आपने मैन्युअल रूप से डेटा को पॉप्युलेट किया है और प्रबंधित किया है कि "इनवॉइस" को वेब पर पुनर्प्राप्त करने के बाद प्रत्येक "ग्राहक" के साथ सेट किया जाना है। यह मुश्किल हो सकता है, विशेष रूप से सभी Async सामान के साथ चल रहा है। आप नहीं जानते कि कौन सी कॉल पहले वापस आएंगी। यहाँ व्याख्या करना कठिन हो सकता है, लेकिन RIA सेवा या "डेटा संदर्भ" सामग्री के बारे में अभी पढ़ेंWCF डेटा सेवाएँ । बिजनेस लाइन के साथ काम करते समय, यह मेरे लिए प्रमुख मुद्दा है। यह मुख्य रूप से उत्पादकता और स्थिरता पर आधारित है। आप डेटा कॉन्‍टेक्‍ट के बिना एप्‍लिकेशन का निर्माण कर सकते हैं। यह सिर्फ चीजों को आसान बनाता है, विशेष रूप से सिल्वरलाइट, डब्ल्यूपीएफ और अब विंडोज 8 मेट्रो में। संबंधपरक एंटिटीज को मेमोरी में अतुल्यकालिक रूप से लोड करना और टू-बाइंडिंग होना वास्तव में अच्छा है।

कहा जाता है कि, इसका मतलब यह है कि किसी दिन WebApi क्लाइंट पर "डेटा संदर्भ" का समर्थन कर सकता है? मुझे लगता है कि यह हो सकता है। इसके अलावा, अधिक टूलिंग के साथ, एक विजुअल स्टूडियो प्रोजेक्ट डेटाबेस स्कीमा (या एंटिटी फ्रेमवर्क) के आधार पर आपके सभी सीआरयूडी तरीकों को उत्पन्न कर सकता है।

इसके अलावा, मुझे पता है कि मैं केवल .NET .NET .NETs का उल्लेख कर रहा हूं, जब यह WCF डेटा सेवाओं या वेबएपीआई के साथ काम करने की बात आती है, लेकिन मुझे पता है कि HTML / JS भी एक प्रमुख खिलाड़ी है। मैं सिर्फ सिल्वरलाइट UI, या ASP.NET सर्वर-साइड कोड, आदि के साथ काम करने के दौरान मिलने वाले लाभों का उल्लेख कर रहा था। मुझे विश्वास है कि HTML5 / जावास्क्रिप्ट में "IndexedDB" के आगमन के साथ "डेटा संदर्भ" और एक नाम है JavaScript में LINQ फ्रेमवर्क भी उपलब्ध हो सकता है, जिससे OData Services को जावास्क्रिप्ट से और भी आसान बनाया जा सकता है (आप डेटाटा का उपयोग आज OData के साथ कर सकते हैं)। इसके अलावा, HTML / JS में MVVM और बाइंडिंग का समर्थन करने के लिए नॉकआउटJS का उपयोग करके, यह एक हवा बना देगा :)

मैं वर्तमान में शोध कर रहा हूं कि किस प्लेटफॉर्म का उपयोग करना है। मुझे इसका उपयोग करके खुशी होगी, लेकिन मैं इस तथ्य के आधार पर ओडता की ओर झुकाव करता हूं कि मेरा अगला एप्लिकेशन मुख्य रूप से Analytics (रीड-ओनली) के बारे में है और मैं एक समृद्ध अभिव्यंजक Restful Api चाहता हूं। मेरा मानना ​​है कि OData + WCF डेटा सेवाएँ मुझे वह देता है क्योंकि WebApi केवल कलेक्शन पर $ टेक, $ स्किप, $ फ़िल्टर, $ ऑर्डरबी का समर्थन करता है। यह अनुमानों का समर्थन नहीं करता है, इसमें ($ विस्तार) शामिल है, आदि में मेरे पास बहुत सारे "अपडेट / डिलीट / इंसर्ट" नहीं हैं और हमारा डेटा काफी रिलेशनल है।

मुझे उम्मीद है कि अन्य लोग चर्चा में शामिल होंगे और अपने विचार देंगे। मैं अभी भी निर्णय कर रहा हूं और अन्य राय सुनना पसंद करूंगा। मुझे वास्तव में लगता है कि दोनों ही रूपरेखाएं महान हैं। मुझे आश्चर्य है कि अगर आपको भी चुनना है, तो आवश्यकता होने पर दोनों का उपयोग क्यों न करें। ग्राहक से यह सभी के बारे में वैसे भी कॉल कर रहे हैं। सिर्फ एक विचार :)

Comments

वेब एपीआई OData समर्थन जोड़ता है कि एक ही नींव पर peacies और पुट यह याद आ रही के लिए एक नया पूर्वावलोकन है कि WCF डी एस का उपयोग करता है: [कड़ी] [ blogs.msdn.com/b/alexj/archive/2012/08/15/...

— जोहानिस रुडोल्फ

@JohannesRudolph - आपके द्वारा दी गई लिंक दिलचस्प लगती है लेकिन टूटी हुई है।

— ऑली

ठीक है, लगता है कि यह सिर्फ स्वरूपण समस्या है। यह होना चाहिए: blogs.msdn.com/b/alexj/archive/2012/08/15/… ।

— ओली

2013 से पहले एक्सेल के संस्करणों पर काम करने के लिए वेब आपी को भी बस इस छोटे से प्यार की ज़रूरत है

— डेविड डी ई फ्रीटास

अब हम 2014 में हैं, माइक्रोसॉफ्ट एक दिलचस्प ब्लॉग पोस्ट है blogs.msdn.com/b/odatateam/archive/2014/03/27/... WCF और WebAPI से OData समर्थन के भविष्य पर चर्चा की।

— हार्डीवांग

Answer 3

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

ओडटा टीम ब्लॉग

तो, लगता है अब सब कुछ पर्याप्त स्पष्ट है

Answer 4

वेब API और WCF डेटा सेवाएँ, दोनों बॉक्स से बाहर OData का समर्थन करती हैं। WCF डेटा सर्विसेज (WCFDS) के साथ, यह स्वचालित है। वेब एपीआई के साथ, IQueryableअपने नियंत्रक से लौटें और विधि को टैग करें [Queryable]। इससे आपको वह $filterकार्यक्षमता मिलेगी जिसके बारे में आप बात कर रहे थे। और यदि आप इसके बारे में इस तरह से जाते हैं, तो दोनों accept=application/jsonअनुरोध हेडर में डालकर JSON को स्वचालित रूप से प्रतिक्रिया में संभाल सकते हैं । डब्ल्यूसीएफडीएस से ओडटा वेब एपीआई की तुलना में कुछ अधिक ओडाटा कीवर्ड का समर्थन करता है (हालांकि केवल $expandकीवर्ड दिमाग में आता है), लेकिन मुझे यकीन है कि समय इसका उपाय करेगा।

.NET क्लाइंट और HTML दोनों पेज इन दोनों विकल्पों में आसानी से कॉल कर सकते हैं, लेकिन अगर आपको LINQ पसंद है, और आप .NET क्लाइंट बना रहे हैं, तो WCFDS को सेवा संदर्भ के रूप में आपके प्रोजेक्ट में जोड़ा जा सकता है। इससे आप सभी HTTP व्यवसाय को पूरी तरह से छोड़ सकते हैं और सीधे संग्रह को क्वेरी कर सकते हैं।

लब्बोलुआब यह है कि आपके ASP.Net MVC प्रोजेक्ट में .svc फ़ाइलों को डालने से कुछ भी नहीं है। यह एक या तो प्रस्ताव नहीं है। अपने सर्वर में डेटा सेवाओं को जोड़ने से आपको बहुत सारे नियंत्रक लिखने की आवश्यकता होगी, लेकिन यदि आप चाहें तो आपको अतिरिक्त नियंत्रक लिखने से नहीं रोका जा सकता है।

Answer 5

दूसरे शब्दों में :

यदि आप किसी डेटा मॉडल (EDM या अन्यथा) को शीघ्रता से उजागर करना चाहते हैं और आपको बहुत सारे कोड या व्यावसायिक तर्क की आवश्यकता नहीं है, तो WCF डेटा सेवाएँ वास्तव में आसान बनाती हैं और यह एक अच्छा प्रारंभिक बिंदु होगा।

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

http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx

Answer 6

Devaron ने WCF बनाम वेब एपी की सबसे अधिक जानकारीपूर्ण समीक्षा दी जो मुझे अभी तक नहीं मिली है। धन्यवाद। अब WCF के बहुत जटिल होने की बात पर, मैं कहूंगा कि जटिलता अपने आप में नकारात्मक नहीं है। आप सांस लेने वाले कमरे के लिए आभारी होंगे जो भविष्य में आपको प्रभावित करता है। हमेशा Microsoft उपकरणों के साथ चुनौती यह है कि हम उस भविष्य को नहीं जानते या नियंत्रित नहीं करते हैं। चलो आशा करते हैं कि Microsoft एक अधिक एकीकृत प्रणाली के साथ समाप्त होता है, और यह कुछ वर्षों के लिए चारों ओर रहता है।

मुझे निर्माण करने के लिए एक बड़ा सिस्टम भी मिला है, और यह मुझे तनाव देता है कि रास्ता अधिक स्पष्ट नहीं है। मैं कुछ और महीनों के लिए अलग रहने की योजना बनाता हूं जबकि यह सब सुलझ जाता है। और व्यक्तिगत रूप से मैं datajs के लिए रूट कर रहा हूं (JayData भी देखें)

Answer 7

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

हाँ, आप इन्हें WCF में स्वयं कार्यान्वित कर सकते हैं लेकिन जैसा कि वाक्य में कहा गया है कि आपको इन्हें स्वयं लागू करने की आवश्यकता है।

एक उदाहरण के रूप में आज एक वेब एपीआई के लिए 2 कारक प्रमाणीकरण को लागू करने में OWIN का उपयोग करते हुए 15 मिनट से कम समय लगता है जो एक मुख्य रूप से प्रमाणीकरण / प्राधिकरण नौगेट पैकेज है जो एक ओपन सोर्स प्रोजेक्ट के रूप में शुरू हुआ था।

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

इसलिए मेरी आपसे सरल सलाह है, यदि आप रिस्टफ़ुल HTTP आधारित अनुप्रयोगों का निर्माण करना चाहते हैं तो वेब एपीआई (या पोर्टेबिलिटी के लिए ASP.NET कोर) का उपयोग करें और वास्तव में WCF से दूर रहें। यदि प्रोटोकॉल HTTP नहीं है और यह वास्तव में HTTP नहीं हो सकता है तो WCF का उपयोग करें।

Answer 8

यह इस प्रश्न का उत्तर है।

WCF डेटा संचार और हस्तांतरण के लिए WEB API के पेचकश के लिए स्विस सेना का चाकू है: WCF वह सब कुछ कर सकता है जो WEB API कर सकता है, लेकिन, यदि आपको और अधिक की आवश्यकता है (जैसे, टीसीपी प्रोटोकॉल का उपयोग करके), WCF जाने का रास्ता है।

यहाँ एक महान तुलना है ।

वेब एपीआई

WEB एपीआई का उपयोग करने के लिए नंबर एक कारण यह है कि यह हल्का है। इसका मतलब यह है कि इसे लागू करना आसान है, सीखना आसान है, बनाए रखना आसान है, आदि यह विशेष रूप से वेब के लिए डिज़ाइन किया गया है, जिसे HTTP पर RESTful वेब सेवाओं की आवश्यकता है। यह ऐसा करता है और यह इसे अच्छी तरह से करता है। अगर, यह आपकी ज़रूरत है, तो WEB एपीआई शायद जाने का रास्ता है।

इसके अलावा, यह ओपन सोर्स है (यदि आप ध्यान दें)

WCF

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

OData

ओडता बस है

एक सरल और मानक तरीके से क्वेरी और इंटरऑपरेबल रेस्टफुल एपीआई के निर्माण और खपत की अनुमति देने के लिए एक खुला प्रोटोकॉल। स्रोत: http://www.odata.org/

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