JSON, REST, SOAP, WSDL और SOA: वे सभी एक साथ कैसे लिंक करते हैं


155

वर्तमान में कुछ परीक्षाएं कर रहा हूं और कुछ अवधारणाओं के माध्यम से संघर्ष कर रहा हूं। इन सभी का मेरे नोटों में 'उल्लेख' किया गया है, लेकिन मुझे वास्तव में समझ नहीं आया कि वे सभी एक साथ कैसे जुड़े। जहाँ तक मेरी समझ है:

SOA - सेवा उपभोक्ताओं / प्रदाताओं को संवाद बनाने के लिए एक समाधान। (जहाँ तक मैं समझता हूँ यह सब कुछ के लिए छत्र शब्द है)

WSDL - एक भाषा जो प्रदाता सेवा का वर्णन करती है।

संदेश भेजने के लिए सेवाओं द्वारा SOAP - एक XML प्रोटोकॉल 'आवरण' का उपयोग किया जाता है। पैरामीटर प्रदान करने के लिए WSDL के साथ संयोजन के रूप में काम करता है?

REST - एक डिज़ाइन पैटर्न जो फ़ंक्शन में SOAP के समान है लेकिन XML से बचा जाता है? (वास्तव में इस बारे में निश्चित नहीं)

JSON - XML ​​का एक विकल्प जो जावास्क्रिप्ट का उपयोग करता है? (इस बारे में निश्चित नहीं है)

इन्टरनेट के इर्द-गिर्द देखने से यह स्पष्ट परिभाषा नहीं बनती है कि ये सभी क्या हैं और ये कैसे परस्पर जुड़ते हैं।

जवाबों:


252

कल्पना कीजिए कि आप एक वेब-एप्लिकेशन विकसित कर रहे हैं और आप एप्लिकेशन की प्रस्तुति से कार्यक्षमता को कम करने का निर्णय लेते हैं, क्योंकि यह अधिक स्वतंत्रता देता है।

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

वेब सेवाएं प्लेटफ़ॉर्म और प्रोग्रामिंग भाषाओं से स्वतंत्र मानक इंटरनेट प्रोटोकॉल पर कार्यात्मक भवन-ब्लॉकों को सुलभ बनाती हैं।

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


यहीं SOAP और REST आते हैं। वे मानक तरीके हैं जिनसे आप वेब-सेवा के साथ संवाद करेंगे।

साबुन:

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

आराम:

REST एक डिजाइन अवधारणा है।

वर्ल्ड वाइड वेब REST वास्तुशिल्प शैली के अनुरूप एक प्रणाली के सबसे बड़े कार्यान्वयन का प्रतिनिधित्व करता है।

यह SOAP जितना कठोर नहीं है। रेस्टफुल वेब-सर्विसेज वेबसर्विस को कॉल करने के लिए मानक यूआरआई और विधियों का उपयोग करती हैं। जब आप किसी URI से अनुरोध करते हैं , तो यह किसी वस्तु का प्रतिनिधित्व लौटाता है , जिससे आप तब ऑपरेशन कर सकते हैं (जैसे GET, PUT, POST, DELETE)। आप डेटा का प्रतिनिधित्व करने के लिए XML लेने तक सीमित नहीं हैं, आप वास्तव में कुछ भी चुन सकते हैं (JSON शामिल)

फ़्लिकर का रीस्ट एपीआई आगे बढ़ता है और आपको छवियों को भी वापस करने देता है।


JSON और XML , कार्यात्मक रूप से समकक्ष और सामान्य विकल्प हैं। जीआरपीसी जैसे प्रोटोक्यूफ़्स और अपाचे थ्रिफ्ट पर आरपीसी आधारित फ्रेमवर्क भी हैं जो एपीआई उत्पादकों और उपभोक्ताओं के बीच संचार के लिए उपयोग किए जा सकते हैं। वेब APIs द्वारा उपयोग किया जाने वाला सबसे आम प्रारूप JSON है क्योंकि यह हर भाषा में उपयोग और पार्स करना आसान है।


36
JSON बनाम XML पर कॉप-आउट के लिए उत्कृष्ट उत्तर। एक और अधिक संतुलित संस्करण होगा: XML और JSON डेटा को क्रमबद्ध करने के तरीके हैं। एक्सएमएल अधिक लचीला है और इसके चारों ओर बहुत सारे मानक हैं, लेकिन कुछ को लगता है कि यह बहुत जटिल और वाचाल है। JSON एक सरल प्रारूप है जो संक्षिप्त तरीकों में कुछ बुनियादी संरचनाओं को परिभाषित करता है, जो अनौपचारिक डेटा संरचनाओं के लिए उपयोग करना आसान है; कुछ लोग XML के शीर्ष पर मौजूद लोगों को दोहराने के लिए इसके शीर्ष पर मानकों पर काम कर रहे हैं।
IMSoP

30

डबल्यूएसडीएल : वेब सेवा विवरण भाषा के लिए खड़ा है

SOAP (सरल ऑब्जेक्ट एक्सेस प्रोटोकॉल) में, जब आप वेब सेवा का उपयोग करते हैं और अपनी परियोजना में एक वेब सेवा जोड़ते हैं, तो आपके क्लाइंट एप्लिकेशन को वेब सेवा कार्यों के बारे में पता नहीं होता है। आजकल यह किसी भी तरह पुराने फैशन का है और हर तरह के क्लाइंट के लिए आपको अलग-अलग WSDLफाइल को लागू करना होगा । उदाहरण के लिए आप क्लाइंट .Netऔर phpक्लाइंट के लिए एक ही फाइल का उपयोग नहीं कर सकते । WSDLफ़ाइल वेब सेवा कार्यों के बारे में कुछ विवरण है। इस फ़ाइल का प्रकार है XMLSOAPके लिए एक विकल्प है REST

बाकी : प्रतिनिधि राज्य हस्तांतरण के लिए खड़ा है

यह एक अन्य प्रकार की एपीआई सेवा है, ग्राहकों के लिए उपयोग करना वास्तव में आसान है। उन्हें फाइल की तरह विशेष फ़ाइल एक्सटेंशन की आवश्यकता नहीं है WSDL। CRUD ऑपरेशन को अलग-अलग किया जा सकता है HTTP Verbs(जीईटी फॉर रीडिंग, पोस्टिंग फॉर क्रिएशन, पीयूटी या अपडेट के लिए पाट और वांछित दस्तावेज को हटाने के लिए DELETE), वे HTTPप्रोटोकॉल पर आधारित होते हैं और ज्यादातर प्रतिक्रिया प्रतिक्रिया JSONया XMLप्रारूप में होती है। दूसरी ओर ग्राहक एप्लिकेशन को HTTP Verbसटीक पैरामीटर नाम और प्रकार के माध्यम से संबंधित कॉल करना होगा । परिभाषा के लिए विशेष फ़ाइल नहीं होने के कारण, जैसे WSDL, यह समापन बिंदु का उपयोग करके मैन्युअल रूप से काम है। लेकिन यह कोई बड़ी बात नहीं है क्योंकि अब हमारे पास क्लाइंट आईडी के कार्यान्वयन के लिए अलग-अलग आईडीई के लिए बहुत सारे प्लगइन्स हैं।

SOA : स्टेंड्स फॉर सर्विस ओरिएंटेड आर्किटेक्चर

वेब सेवाओं की अवधारणाओं और वास्तुकला के साथ प्रोग्रामिंग के सभी शामिल हैं। कल्पना कीजिए कि आप एक बड़े पैमाने पर आवेदन को लागू करना चाहते हैं। एक अभ्यास में कुछ अलग सेवाएं हो सकती हैं, जिन्हें माइक्रो-सर्विसेज कहा जाता है और पूरे एप्लिकेशन तंत्र को सही समय पर आवश्यक वेब सेवा कहा जाएगा। दोनों RESTऔर SOAPवेब सेवाएं एक तरह की हैं SOA

JSON : के लिए खड़ा हैjavascript Object Notation

जब आप किसी ऑब्जेक्ट को जावास्क्रिप्ट के लिए क्रमबद्ध करते हैं तो ऑब्जेक्ट फॉर्मेट का प्रकार JSON होता है। कल्पना कीजिए कि आपके पास मानव वर्ग है:

class Human{
 string Name;
 string Family;
 int Age;
}

और आपके पास इस वर्ग से कुछ उदाहरण हैं:

Human h1 = new Human(){
  Name='Saman',
  Family='Gholami',
  Age=26
}

जब आप JSON के h1 ऑब्जेक्ट को क्रमबद्ध करते हैं तो परिणाम होता है:

  [h1:{Name:'saman',Family:'Gholami',Age:'26'}, ...]

javascripteval()फ़ंक्शन द्वारा इस प्रारूप का मूल्यांकन कर सकते हैं और इस JSONस्ट्रिंग से एक सहयोगी सरणी बना सकते हैं । पूर्व में वर्णित अन्य अवधारणाओं की तुलना में यह एक अलग अवधारणा है।


इस उत्तर में कुछ गलतियाँ हैं (उदाहरण के लिए HTML <> HTTP)
यिसन हज

1
@YassinHajaj तय
समन घोलमी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.