REST और CRUD के बीच अंतर


168

मैंने रीस्ट सीखा और यह सीआरयूडी (सीआरयूडी के बारे में मैंने जो भी पढ़ा है) से बहुत कुछ महसूस करता है।

मुझे पता है कि वे अलग हैं, और मुझे आश्चर्य है कि अगर वे इसी तरह सोच रहे हैं तो मैं उन्हें समझ नहीं पा रहा हूं।

क्या यह है कि REST CRUD का "सुपरसेट" है? क्या सब कुछ CRUD और अधिक करता है?


17
वे सोच समान अर्थ यह है कि आप कर रहे हैं करते हैं उन्हें समझ। उत्तरों को पढ़ने में, मुझे आश्चर्य होता है और जो मैं अवधारणाओं के बीच समानता को स्वीकार नहीं करने का गलत स्तर मानता हूं । मेरा मानना है कि बाकी को समझने के लिए सही तरीका है कि है "HTTP संसाधनों के लिए CRUD" के रूप में यह सोचने के लिए। यदि आप समझते हैं कि HTTP संसाधन क्या है (यह डेटाबेस रिकॉर्ड के समान नहीं है) और आप जानते हैं कि CRUD क्या है, तो REST को "HTTP रिसोर्स के लिए CRUD" के रूप में वर्णन करना REST का सार बताने का एक सही और संक्षिप्त तरीका है।
जेसन लिवेसे

जवाबों:


205

हैरानी की बात है, मैं अन्य उत्तरों में नहीं देखता कि मैं REST और CRUD के बीच वास्तविक अंतर पर क्या विचार करता हूं: प्रत्येक एक का प्रबंधन करता है।

CRUD का अर्थ है डेटा रिपॉजिटरी में किए जाने वाले बुनियादी ऑपरेशन। आप सीधे रिकॉर्ड या डेटा ऑब्जेक्ट संभालते हैं; इन परिचालनों के अलावा, अभिलेख निष्क्रिय निकाय हैं। आमतौर पर यह सिर्फ डेटाबेस टेबल और रिकॉर्ड है।

दूसरी ओर, REST संसाधन अभ्यावेदन पर संचालित होता है, हर एक URL द्वारा पहचाना जाता है। ये आमतौर पर डेटा ऑब्जेक्ट नहीं होते हैं, लेकिन जटिल ऑब्जेक्ट एब्स्ट्रैक्ट होते हैं।

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

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

इसके अलावा, एक संसाधन प्रतिनिधित्व में हाइपरटेक्स्ट ( HATEOAS सिद्धांत की जांच करें ) शामिल है, जिससे डिजाइनर को संसाधनों के बीच संबंधों को व्यक्त करने की अनुमति मिलती है, या ऑपरेशन के वर्कफ़्लो में REST क्लाइंट का मार्गदर्शन किया जाता है।

संक्षेप में, CRUD एक सेट आदिम संचालन है (ज्यादातर डेटाबेस और स्थिर डेटा स्टोरेज के लिए), जबकि REST एक बहुत ही उच्च-स्तरीय एपीआई शैली है (ज्यादातर वेब सेवाओं और अन्य 'लाइव' प्रणालियों के लिए)।

पहला एक बुनियादी डेटा में हेरफेर करता है, दूसरा एक जटिल प्रणाली के साथ बातचीत करता है।


3
@ जेवियर उन्हें अलग स्थापित करने के लिए धन्यवाद। मैंने REST लर्निंग रेल्स का इस्तेमाल किया और मुझे आभास हुआ कि यह CRUD के लिए एक रिप्लेसमेंट था (जिसके बारे में मुझे तब से पता चला ... वह नाम जो है, मैं पहले से ही इसका इस्तेमाल कर रहा था, बस यह नहीं पता था कि इसे क्या कहा जाए) ... You सेब और संतरे की तुलना करने के लिए 2 सेबों की तुलना से बाकी बनाम सीआरयूडी को बदल दिया। साभार
जेसी ब्लैक

2
@Maudicus: मुझे लगता है कि यह बहुत आम है, क्योंकि RoR में CRUD लेयर (जैसा कि सबसे (हर?) फ्रेमवर्क होता है) शामिल है, और यह उसके ऊपर एक REST API जोड़ने के लिए आसान (ऑटोमैटिक?) बनाता है, यह सोचना आसान है। सभी REST क्या है। लेकिन फिर आप CRUD के शीर्ष पर कार्यक्षमता जोड़ सकते हैं, लेकिन REST API के पीछे, उन्हें अधिक से अधिक अलग बना सकते हैं।
जेवियर

1
आपका उत्तर सही है, लेकिन उदाहरण इष्टतम नहीं है: एक टिप्पणी एक एकल डीबी पंक्ति को उबाल सकती है, और क्या डीबी ट्रिगर के साथ संबंधित वस्तुओं के लिए गतिशील परिवर्तन लागू करना संभव नहीं है? मुझे लगता है कि बाकी आपी में सिर्फ क्रूड ऑपरेशन से थोड़ा अधिक है, और आपका जवाब स्पष्ट रूप से अच्छी तरह से महसूस होता है।
दीदीक जूल 21'14

2
तो ... एक ही बात, अलग परत :)
AlikElzin-kilaka

इसे व्यक्त करने के लिए बहुत-बहुत धन्यवाद! मैं जोड़ता हूं कि HTTP ऑपरेशनों में CRUD संचालन की सीमा REST को सचमुच CRUD के रूप में लागू करने का परिणाम है, जिसमें बहुत सारे उपकरण हैं जो CRUD बॉयलरप्लेट को सामान्य करते हैं और इस रिवाज के लिए एक जगह "टिप्पणी पर काम करना" तर्क को याद करते हैं।
सोमपिलसार

99

सबसे पहले, दोनों बस सामान्य आद्याक्षर हैं; वे डरने वाले नहीं हैं।

अब, CRUD एक सरल शब्द है जिसे संक्षिप्त रूप में दिया गया था क्योंकि यह कई अनुप्रयोगों में एक सामान्य विशेषता है, और CRUD कहना आसान है । यह उन 4 मूल ऑपरेशनों का वर्णन करता है जिन्हें आप डेटा (या संसाधन) पर निष्पादित कर सकते हैं। बनाएं, पढ़ें, अपडेट करें, हटाएं।

REST हालांकि, एक नामित अभ्यास है (AJAX की तरह), अपने आप में एक तकनीक नहीं। यह उन क्षमताओं के उपयोग को प्रोत्साहित करता है जो लंबे समय से HTTP प्रोटोकॉल में निहित हैं, लेकिन शायद ही कभी इसका इस्तेमाल किया गया हो।

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

प्रत्येक अनुरोध में एक URL होता है, इसलिए सर्वर जानता है कि आप किस संसाधन तक पहुंचना चाहते हैं, लेकिन इसमें एक विधि भी हो सकती है । एक विधि बताती है कि उस संसाधन का क्या करना है

लेकिन इस "विधि" अवधारणा का बहुत बार उपयोग नहीं किया गया था।

आमतौर पर, लोग केवल GET पद्धति के माध्यम से पृष्ठों से लिंक करते हैं, और POST विधि के माध्यम से किसी भी प्रकार के अपडेट (विलोपन, प्रविष्टि, अपडेट) जारी करते हैं।

और उसके कारण आप एक संसाधन (URL) को अपने आप में एक सच्चे संसाधन के रूप में नहीं मान सकते। आपके पास एक ही संसाधन को हटाने, प्रविष्टि या अद्यतन के लिए अलग URL होने चाहिए। उदाहरण के लिए:

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

REST के साथ, आप ऐसे फ़ॉर्म बनाते हैं, जो होशियार होते हैं क्योंकि वे POST से हटकर अन्य HTTP विधियों का उपयोग करते हैं, और अपने सर्वर को केवल URL के अनुसार, विधियों के बीच अंतर करने में सक्षम बनाते हैं । उदाहरण के लिए:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

याद रखें, एक एकल URL एक एकल संसाधन का वर्णन करता है। एक एकल पोस्ट एक एकल संसाधन है। REST के साथ आप संसाधनों का इलाज करते हैं जिस तरह से वे इलाज के लिए थे। आप सर्वर को बता रहे हैं कि आप किस संसाधन को संभालना चाहते हैं, और इसे कैसे संभालना है।

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


4
खेद है, लेकिन बाकी है CRUD तुलना में बहुत अधिक। ज्यादातर इसलिए क्योंकि संसाधन एक एकल रिकॉर्ड की तुलना में बहुत अधिक अवतार लेते हैं, और प्रत्येक ऑपरेशन रिकॉर्ड को अपडेट करने की तुलना में बहुत अधिक करता है।
जेवियर

11
ठीक। मैं सहमत हूँ। तुम्हें किस बात का खेद है? मैंने यह नहीं कहा कि यह सीआरयूडी से बहुत अधिक नहीं था। मुझे लगता है कि जैसा मैंने कहा, वैसा ही हुआ
यम मारकोविच नोव

4
यह सही उत्तर होना चाहिए।
ब्रैंडन

HTML विनिर्देश केवल फॉर्म जमा करने के लिए GET और POST विधियों की अनुमति देता है, इसलिए AJAX के व्यापक होने से पहले वेबक्लेर से अनुरोधों को संभालने वाली सेवाओं में अन्य विधियों का उपयोग नहीं किया गया था। कुछ सेवाएँ "_method" नाम के साथ एक छिपे हुए इनपुट फ़ील्ड का उपयोग POST के अलावा एक विधि को निर्दिष्ट करने के लिए वर्कअराउंड के रूप में करती हैं जबकि अभी भी POST विधि का उपयोग करके फ़ॉर्म सबमिट करती हैं।
केनेथ सुंडक्विस्ट

20

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

REST काफी शामिल हो जाता है, क्योंकि REST के पीछे का सिद्धांत रिमोट सिस्टम पर जानकारी का प्रबंधन करने के लिए मीडिया, हाइपरमीडिया, और एक अंतर्निहित प्रोटोकॉल का लाभ उठाता है।

दूसरी ओर, CRUD एक डेटाबेस में डेटा के लिए आवश्यक सामान्य ऑपरेशन के लिए एक महामारी है: रिट्रीव अपडेट अपडेट हटाएं। लेकिन यह वास्तव में उससे ज्यादा गहरा नहीं है।

तो यह आपके प्रश्न का उत्तर है, लेकिन मैं उस सामान्य गलती का उल्लेख करूंगा जो मैं देखता हूं जब REST और CRUD पर एक साथ चर्चा की जाती है। बहुत सारे डेवलपर REST को सीधे CRUD में मैप करना चाहते हैं, क्योंकि HTTP पर REST GET PUT POST और DELETE के लिए प्रदान करता है, जबकि CRUD क्रीएट रिट्रीवेट UPDATE DELETE के लिए प्रदान करता है। यह स्वाभाविक है कि REST क्रियाओं को सीधे CRUD संचालन में मैप करना चाहिए।

हालाँकि, HTTP एक "क्रिएट या अपडेट" शैली का उपयोग करता है, जबकि CRUD क्रिएट और अपडेट को अलग करता है। इससे दोनों के बीच एक साफ, सामान्य मानचित्रण करना असंभव हो जाता है (!)

GET और DELETE आसान है ... GET === RETRIEVE, और DELETE === DELETE।

लेकिन HTTP युक्ति के अनुसार, PUT वास्तव में Create and Update है:

  • जब आप इसके बारे में सब कुछ जानते हैं, तो इसके पहचानकर्ता सहित एक नई वस्तु बनाने के लिए PUT का उपयोग करें

  • ऑब्जेक्ट को अपडेट करने के लिए PUT का उपयोग करें (आमतौर पर ऑब्जेक्ट का पूर्ण प्रतिनिधित्व)

POST "प्रसंस्करण" क्रिया है, और इसे "परिशिष्ट" क्रिया माना जाता है:

  • एक संग्रह में एक नई वस्तु को जोड़ने के लिए POST का उपयोग करें - अर्थात, एक नई वस्तु बनाएं

  • POST का उपयोग तब भी किया जाता है जब कोई अन्य क्रिया काफी फिट नहीं होती, क्योंकि HTTP कल्पना इसे "डेटा प्रोसेसिंग" क्रिया के रूप में परिभाषित करती है

  • यदि आपकी टीम POST पर टिकी हुई है, तो याद रखें कि पूरा WWW GET और POST पर बनाया गया था;)

इसलिए जब REST और CRUD के बीच समानता होती है, तो जो गलती मैं देखता हूं कि ज्यादातर टीमें दोनों के बीच तालमेल बिठाती हैं। एक टीम को वास्तव में सावधान रहने की आवश्यकता होती है जब किसी REST API को परिभाषित करने के लिए CRUD mnemonic पर लटका हुआ नहीं मिलता है, क्योंकि REST एक अभ्यास के रूप में वास्तव में बहुत अधिक अतिरिक्त जटिलता है जो CRUD को साफ-साफ मैप नहीं करता है।


7

CRUD डेटा पढ़ने और लिखने के लिए बुनियादी भंडारण क्रियाओं का एक न्यूनतम सेट निर्दिष्ट करता है: बनाएं, पढ़ें, अपडेट करें और हटाएं। फिर, आप इनका संयोजन करके अन्य ऑपरेशन का निर्माण कर सकते हैं। इन्हें आमतौर पर डेटाबेस ऑपरेशन माना जाता है, लेकिन जो डेटाबेस माना जाता है वह मनमाना है (उदाहरण के लिए, रिलेशनल DBMS हो सकता है, लेकिन YAML फाइलें भी हो सकती हैं)।

REST एक "वास्तुशिल्प शैली" है जिसमें आमतौर पर CRUD संचालन और अन्य, उच्च स्तर के संचालन शामिल होते हैं, जो सभी को "संसाधनों" की कुछ अवधारणा पर निष्पादित किया जाना है (मनमाना, लेकिन ये आपके आवेदन में संस्थाएं हैं)। REST में बाधाओं का एक समूह है जो इसे दिलचस्प बनाता है (और विशेष रूप से HTTP के साथ अच्छी तरह से जोड़ा जाता है)।

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


धन्यवाद यार। ऐसा लगता है कि मेरा "सब कुछ सीआरयूडी करता है और अधिक?" हाँ, एक डेटाबेस में सिर्फ प्रविष्टियों से अधिक पर REST की तकनीकीता लागू होती है।
जेसी ब्लैक

@Maudicus मैंने उत्तर को अपडेट किया, लेकिन विशिष्ट होने के लिए: यह हो सकता है लेकिन ऐसा नहीं है।
डैन रोसेनस्टार्क

मैं यह नहीं कहूंगा कि वे आपके आवेदन को पूरा करने के लिए आवश्यक हैं। कुछ अनुप्रयोगों को प्रकृति द्वारा सम्मिलन, निष्कासन या अपडेट की आवश्यकता नहीं है।
यम मारकोविक नोव

@ यम मार्कोविच, ठीक है, समायोजित
डैन रोसेनस्टार्क

6

CRUD

  • CRUD SQL कमांड के चार मूल प्रकार हैं: क्रिएट, रीड, अपडेट और डिलीट
  • अधिकांश अनुप्रयोगों में किसी न किसी प्रकार की CRUD कार्यक्षमता होती है
  • एक CRUD एप्लिकेशन वह होता है जो किसी डेटाबेस में डेटा प्राप्त करने के लिए रूपों का उपयोग करता है

आराम

  • REST का अर्थ है प्रतिनिधि राज्य अंतरण। (इसे कभी-कभी "ReST" कहा जाता है)

  • यह एक स्टेटलेस, क्लाइंट-सर्वर, कैशेबल संचार प्रोटोकॉल पर निर्भर करता है - और लगभग सभी मामलों में, HTTP प्रोटोकॉल का उपयोग किया जाता है

  • REST नेटवर्कयुक्त अनुप्रयोगों को डिजाइन करने के लिए एक वास्तुकला शैली है


2

REST मशीनों के लिए एक वेबपेज की तरह है, जिसे वे ब्राउज़ कर सकते हैं, जबकि CRUD SOAP जैसा कुछ है, जो अपने ग्राहकों के लिए दृढ़ता से युग्मित है। ये मुख्य अंतर हैं। ऑप्टिकल फाइबर केबल। वे सतह पर समान हैं, लेकिन CRUD बुनियादी इकाई हेरफेर का वर्णन करता है, जबकि REST किसी भी अनुप्रयोग के इंटरफ़ेस का वर्णन कर सकता है। एक और अंतर जो REST 4 HTTP विधियों का अधिक उपयोग कर सकता है। यह एक बहुत लंबा जवाब होगा यदि मैं सभी मतभेदों को इकट्ठा करना चाहता हूं, यदि आप REST बनाम SOAP के बारे में प्रश्नों की जांच करते हैं, तो आप उनमें से अधिकांश पाएंगे।

मुझे लगता है कि CRUD के साथ REST को भ्रमित करना एक बहुत ही सामान्य गलती है और इसका कारण यह है कि डेवलपर्स के पास REST के बारे में गहराई से पढ़ने का समय नहीं है। वे केवल तकनीक का उपयोग करना चाहते हैं - इसे समझे बिना - समान डेवलपर्स द्वारा लिखित सीमित CRUD शैली के उदाहरणों के आधार पर। उदाहरण और ट्यूटोरियल के विशाल बहुमत ज्ञान की गंभीर कमी को दर्शा रहे हैं। इन संस्थाओं के संचालन के लिए संस्थाओं और HTTP तरीकों के लिए REST संसाधनों का मानचित्रण करना और हाइपरलिंक के बिना REST का उपयोग करना केवल इसका एक लक्षण है। REST द्वारा आप अपने कार्यों के लिए हाइपरलिंक्स (POST / PUT / DELETE / PATCH विधियों के लिंक सहित) को मैप करते हैं और आप (आमतौर पर API विशिष्ट) लिंक रिलेशन की जाँच करके क्लाइंट की तरफ ऑपरेशन की पहचान करते हैं। यदि कोई REST क्लाइंट नहीं जानता कि लिंक संबंध क्या है, और केवल HTTP तरीके और शायद कुछ URI टेम्प्लेट जानता है, तब वह REST क्लाइंट नहीं है, लेकिन HTTP क्लाइंट पर एक CRUD है। एक अन्य सामान्य गलती है कि एक REST क्लाइंट एक एकल पेज जावास्क्रिप्ट अनुप्रयोग है जो ब्राउज़र में चल रहा है। बेशक आप इस तरह के क्लाइंट को लागू कर सकते हैं, लेकिन REST मुख्य रूप से ऑटोमैटिक क्लाइंट्स के लिए था (सर्वर साइड एप्लिकेशन जिन्हें आप भी नहीं जानते हैं डेवलपर्स द्वारा लिखा गया है) और मैनुअल क्लाइंट (आपके द्वारा लिखे गए उपयोगकर्ता नियंत्रित ब्राउज़र एप्लिकेशन) के लिए नहीं। केवल एक ही ब्राउज़र क्लाइंट होने से यह संकेत हो सकता है कि आपको वास्तव में REST की आवश्यकता नहीं है और आपने केवल परियोजना को चुनौती दी है। इन मामलों में एक CRUD एपीआई एक व्यवहार्य समाधान है और डेवलपर्स इन CRUD API को REST कह रहे हैं, क्योंकि वे अंतर नहीं जानते हैं। बेशक आप इस तरह के क्लाइंट को लागू कर सकते हैं, लेकिन REST मुख्य रूप से ऑटोमैटिक क्लाइंट्स के लिए था (सर्वर साइड एप्लिकेशन जिन्हें आप भी नहीं जानते हैं डेवलपर्स द्वारा लिखा गया है) और मैनुअल क्लाइंट (आपके द्वारा लिखे गए उपयोगकर्ता नियंत्रित ब्राउज़र एप्लिकेशन) के लिए नहीं। केवल एक ही ब्राउज़र क्लाइंट होने से यह संकेत हो सकता है कि आपको वास्तव में REST की आवश्यकता नहीं है और आपने केवल परियोजना को चुनौती दी है। इन मामलों में एक CRUD एपीआई एक व्यवहार्य समाधान है और डेवलपर्स इन CRUD API को REST कह रहे हैं, क्योंकि वे अंतर नहीं जानते हैं। बेशक आप इस तरह के क्लाइंट को लागू कर सकते हैं, लेकिन REST मुख्य रूप से ऑटोमैटिक क्लाइंट्स के लिए था (सर्वर साइड एप्लिकेशन जिन्हें आप भी नहीं जानते हैं डेवलपर्स द्वारा लिखा गया है) और मैनुअल क्लाइंट (आपके द्वारा लिखे गए उपयोगकर्ता नियंत्रित ब्राउज़र एप्लिकेशन) के लिए नहीं। केवल एक ही ब्राउज़र क्लाइंट होने से यह संकेत हो सकता है कि आपको वास्तव में REST की आवश्यकता नहीं है और आपने केवल परियोजना को चुनौती दी है। इन मामलों में एक CRUD एपीआई एक व्यवहार्य समाधान है और डेवलपर्स इन CRUD API को REST कह रहे हैं, क्योंकि वे अंतर नहीं जानते हैं।

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