आरईएसटी वेब की वर्तमान विशेषताओं का उपयोग कर रहा है और इसे और अधिक कुशल बनाने के लिए कुछ सिद्धांतों को लागू कर रहा है। यह संचार के लिए मानक HTTP क्रियाओं का उपयोग करता है और इसकी स्टेटलेस प्रकृति की मदद लेता है।क्या मैं एक विश्वसनीय सेवा में टीसीपी का उपयोग कर सकता हूं?
हालांकि, क्या यह संभव है कि एक आरईएसटी सेवा अपने संचार के लिए टीसीपी प्रोटोकॉल का उपयोग करे? यदि हां, तो क्या यह इसके सिद्धांतों का उल्लंघन करेगा?
HTTP एक टीसीपी/आईपी आधारित प्रोटोकॉल है। तो जब आप आरईएसटी का उपयोग करते हैं तो आप संचार के लिए पहले ही टीसीपी का उपयोग कर रहे हैं। लेकिन यदि आप HTTP के बिना शुद्ध टीसीपी सॉकेट पर आरईएसटी का उपयोग करना चाहते हैं, तो नहीं, यह समझ में नहीं आता है क्योंकि आरईएसटी HTTP क्रियाओं और शीर्षकों पर आधारित है। वे धारणा केवल HTTP प्रोटोकॉल में मौजूद हैं।
लेकिन डब्ल्यूसीएफ इस तरह से विकसित किया गया है कि केवल बाइंडिंग को बदलकर एक ही सेवा HTTP, टीसीपी, आईपीसी या अन्य प्रोटोकॉल के साथ काम कर सकती है, तो इसका मतलब है कि यह डब्ल्यूसीएफ फीचर्स बाकी डब्ल्यूसीएफ सेवा पर समर्थित नहीं हैं। – funsukvangdu
आप केवल HTTP के साथ आरईएसटी का उपयोग कर सकते हैं। –
क्या यह पूरी तरह से सच है कि आरईएसटी HTTP पर निर्भर है? – MBen
आप आराम आधारित सेवाओं के लिए एचटीपी को छोड़कर अन्य बाध्यकारी का उपयोग नहीं कर सकते हैं। यह बाकी के कारण एक वास्तुशिल्प शैली है जो कुछ सिद्धांतों पर आधारित है। इस सिद्धांत में से एक वेब के स्टेटलेस प्रोटोकॉल की मदद लेना है जो http है, यह भी टीटीपी प्रोटोकॉल
पर उपलब्ध नहीं है जैसे डारिन पहले से ही answered के रूप में एचटीपी शब्द जैसे गेट, पोर्ट, पुट और डिलीट जैसे एचटीपी शब्द चाहते हैं, HTTP कुछ ओवरहेड के साथ एक टीसीपी प्रोटोकॉल है जो वास्तव में परिभाषित परिभाषा में उपयोग किया जाता है। तो, नहीं, आप HTTP ओवरहेड को नहीं हटा सकते हैं।
मुझे विश्वास है कि आपके सवाल का "मैं टीसीपी एक तेजी से RESTful अनुप्रयोग के लिए उपयोग कर सकते हैं?" सवाल से संबंधित है "क्यों इतने सारे वेबसाइटों बाकी उपयोग कर रहे हैं HTTP शुद्ध टीसीपी की तुलना में धीमी है?"।
सत्य है: HTTP शुद्ध द्विआधारी टीसीपी रूप से वास्तव में धीमी है, लेकिन सबसे अनुप्रयोगों में, अपने उपयोगकर्ताओं अंतर नोटिस नहीं होगा, क्योंकि भूमि के ऊपर वास्तव में बहुत छोटा है और आम तौर पर ग्राहक सिर्फ एक कर देगा प्रति मिनट कुछ अनुरोध।
उदाहरण के लिए: GET /posts?userId=5
इस अनुरोध को कुछ मिलीसेकेंड पूरा करने के लिए अधिक से अधिक लेता है, तो समस्या HTTP प्रोटोकॉल में नहीं है। प्रदर्शन समस्या नेटवर्क विलंबता से संबंधित है, आपके सर्वर-साइड कोड के साथ और आप अपने डेटाबेस से डेटा कैसे प्राप्त कर रहे हैं।
दूसरी ओर, यदि आपका ग्राहक कोड प्रति मिनट हजारों अनुरोध कर रहा है, तो यह एकल क्लाइंट HTTP ओवरहेड से संबंधित प्रदर्शन समस्या को नोटिस करेगा। इस मामले में, हो सकता है कि आप एक ही ऑपरेशन में कई परिचालनों को बैच कर सकें और नेटवर्क अनुरोधों की मात्रा को कम कर सकें।
यदि एक ग्राहक को वास्तव में प्रति मिनट हजारों अनुरोध करने की आवश्यकता है, तो आप आरईएसटी से बचने और किसी अन्य दृष्टिकोण की तलाश शुरू करने के बारे में सोच सकते हैं। बस याद रखें कि एसओएपी एक टीसीपी बाध्यकारी का उपयोग कर सकता है, लेकिन अनुरोधों के एक्सएमएल को पार्स करने के लिए ओवरहेड भी हैं। इसके अलावा, एसओएपी राज्यपूर्ण है और HTTP स्टेटलेस है। स्केलेबिलिटी के लिए एक राज्यव्यापी दृष्टिकोण खराब है।
थोड़ा अलग कोण:
1। आरईएसटी आधारित सेवाओं को बनाने के लिए डब्ल्यूसीएफ का उपयोग न करें। Asp.Net WebAPI का उपयोग करें।
2। बस मस्ती के लिए: यदि आप 'आरईएसटी' सिद्धांतों के साथ डब्ल्यूसीएफ टीसीपी बाइंडिंग का उपयोग करना चाहते हैं, तो शायद आप एक सामान्य आरपीसी की बजाय 'संसाधन' के आधार पर एक स्टेटलेस एपीआई बना सकते हैं।
[ServiceContract]
interface RestApi
{
Result Get(string id);
Result Post(string id, Resource resource);
Result Put(string id, Resource resource);
void Delete(string id);
}
इस तरह आपको हर सेवा के लिए अलग-अलग अनुबंध को परिभाषित नहीं करना होगा और अलग-अलग इंटरैक्शन के लिए अपने संसाधनों को समायोजित करना होगा।
नोट: मैं किसी को ऐसा करने का सुझाव नहीं दे रहा हूं: यह पहिया को फिर से शुरू कर रहा है। यदि आप आरईएसटी चाहते हैं तो वेबएपीआई का प्रयोग करें।
मैंने कभी नहीं सुना है कि आरईएसटी के "प्रिंसिपल" इसे अधिक कुशल बनाने के उद्देश्य से हैं। –