एक छोटी निश्चित शब्दावली को Restful सेवाओं के लाभ के रूप में क्यों देखा जाता है?


13

तो, एक RESTful सेवा की शब्दावली में क्रियाओं का एक निश्चित समूह होता है। Restful वेब सेवा इन HTTP तरीकों से लेती है। एक निश्चित शब्दावली को परिभाषित करने के कुछ कथित फायदे हैं, लेकिन मैं वास्तव में इस बात को समझ नहीं पाता हूं। शायद कोई इसे समझा सकता है।

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

REST को इस दृष्टि से लाभप्रद माना जाता है कि यह शब्दावली का विस्तार किए बिना विकसित हो सकता है। अन्य संसाधनों को जोड़कर गतिशील सेवाएं गतिशील रूप से बढ़ती हैं। एक वस्तु-वस्तु शब्दावली को गतिशील रूप से निर्दिष्ट करके एक सेवा का विस्तार करने में क्या गलत है? हम केवल उन वस्तुओं का उपयोग क्यों नहीं करते हैं जो शब्दावली के रूप में हमारी वस्तुओं पर परिभाषित हैं और हमारी सेवाएं क्लाइंट को बताती हैं कि ये विधियां क्या हैं और क्या उनके दुष्प्रभाव हैं या नहीं?

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

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

मुझे अभी समझ नहीं आया कि किसी निश्चित शब्दावली को किसी भी आत्म-गतिशील डायनेमिक शब्दावली से बेहतर क्या कहा जा सकता है, जो आरपीसी जैसी सेवा में आसानी से काम कर सकती है। क्या यह HTTP प्रोटोकॉल की सीमित शब्दावली के लिए सिर्फ एक घटिया तर्क है?

प्रतिबिंब

बस अपने विचारों को स्पष्ट करने के लिए जितना मैंने किया है उससे बेहतर है। मान लीजिए कि आप किसी भी सामान्य प्रयोजन एपीआई को डिजाइन कर रहे हैं, शायद वेब फेसिंग भी नहीं। क्या आप खुश होंगे यदि कोई कहे कि आप केवल अपनी वस्तुओं पर इन विधियों के नाम का उपयोग कर सकते हैं? REST HTTP तक ही सीमित नहीं है, लेकिन उस स्थिति पर विचार करें जहां आप प्रत्येक एपीआई लिखते हैं, वेब का सामना करना पड़ रहा है या अन्यथा बस GET POST PUT और DELETE विधियों वाली वस्तुओं से मिलकर बना है। तो उस ऑब्जेक्ट .foo विधि को आप परिभाषित करना चाहते थे संभव नहीं है। आपको फू नामक एक नई वस्तु को परिभाषित करना होगा, और इसकी GET विधि को कॉल करना होगा। यह अनिवार्य रूप से है कि REST कैसे काम करता है, और यह मुझे इसके बारे में सोचने में थोड़ा असहज करता है। आपको इस बात की कोई बेहतर समझ नहीं है कि फू क्या करता है, आपको मूल वस्तु पर एक विधि के लिए एक नई वस्तु बनाने के लिए मजबूर किया गया था। इसके अलावा आपका एपीआई कोई कम जटिल नहीं है, आपके पास अधिक ऑब्जेक्ट्स बनाकर केवल इंटरफ़ेस जटिलता छिपी है। रेस्टफुल वेब सेवाएं हमें एक ऐसे इंटरफ़ेस को अपनाने के लिए मजबूर करती हैं, जो हमारे द्वारा उजागर किए जा रहे एपीआई के संदर्भ में पर्याप्त हो सकता है या नहीं। शायद वेब का सामना करने वाले एपीआई के साथ ऐसा करने का एक अच्छा कारण है, लेकिन प्रत्येक अतिरिक्त कंप्यूटर एपीआई में हर वस्तु के लिए मानक इंटरफेस न अपनाने का एक अच्छा कारण है। एक व्यावहारिक उदाहरण की सराहना की जाएगी।


उपयोगकर्ताओं को आपके प्रश्न और उत्तरों को तुरंत पार्स करने में मदद करने के लिए, आप अपने "अपडेट" को अलग-अलग उत्तर (विशेष रूप से "एक और अपडेट" अनुभाग) के रूप में जोड़ने पर विचार कर सकते हैं। इसे प्रोत्साहित किया गया है: blog.stackoverflow.com/2011/07/…
जोहान

@ जोहान धन्यवाद, अब और अपडेट इस सवाल के स्वीकृत जवाब के रूप में मौजूद हैं।
मैट Esch

जवाबों:


9

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

REST की "क्रियाएं" अपने तरीकों को गेटर्स, सेटरर्स (डिलीटर्स; इन्हें सेटर्स की तरह माना जा सकता है) और अन्य को वर्गीकृत करने की तरह है। और गेटर्स और सेटरों के साथ सब कुछ करने की कोशिश कर रहा है। इसका कारण यह है:

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

HTTP को शुरुआत से ही कैश और दोष-सहिष्णुता दोनों को ध्यान में रखकर बनाया गया था, इसलिए ये दो बिंदु इसके चार मूल तरीके हैं:

  • GETएक गटर है। यह माना जाता है कि सर्वर स्थिति को संशोधित नहीं करने और समाप्ति और पुनर्मूल्यांकन नीति को निर्दिष्ट करने की संभावना के साथ हर बार समान मूल्य लौटाता है।
  • PUTऔर DELETEसेटर और डेलेटर (नील के साथ सेटर) हैं। वे सामान्य रूप से सामान्य वेब के संदर्भ में उपयोग नहीं किए जाते हैं, लेकिन REST के लिए समझ में आते हैं।
  • POST एक सामान्य "आह्वान" किचन सिंक है जिसके लिए कैश कुछ भी नहीं मान सकता है।

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

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


2

आवश्यक विचार यह है कि संसाधन प्रतिनिधित्व के माध्यम से जटिलता व्यक्त की जाती है, और इसलिए अतिरिक्त क्रियाओं की आवश्यकता नहीं होती है। जैसा कि कुछ लोगों ने कहा है - "REST में, संज्ञाएं अच्छी हैं, क्रियाएं खराब हैं।"

यदि आप चार REST क्रियाओं को देखते हैं, तो उन्हें मूल CRUD परिचालनों में मैप किया जा सकता है, अनिवार्य रूप से आपको अपने संसाधनों के साथ जो कुछ भी करना है, करने की अनुमति देता है। अर्थात् -

पोस्ट - संसाधन बनाएँ

प्राप्त करें - संसाधन पढ़ें

PUT - संसाधन को अपडेट करें

DELETE - संसाधन हटाएं

आपको और क्या चाहिए?


मैं इसे करने के लिए एक संसाधन बनाकर एक RESTful सेवा में एक क्रिया को सुविधाजनक बना सकता हूं। जैसा कि आप कहते हैं, मुझे अतिरिक्त क्रियाओं की आवश्यकता नहीं है, बस अधिक से अधिक रिसोर्सेस चाहिए। मैं अभी यह नहीं देखता कि किसी भी अमूर्त क्रिया का दिखावा करना क्यों बेहतर है। जब मैं वास्तव में क्रिया करना चाहता हूं तो एक संज्ञा है। ऐसा लगता है कि क्रियाओं को बिना किसी कारण के जबरन विवश किया जाता है, और मैं क्रियाओं के छोटे सेट के साथ एक्सेस किए जाने पर आवश्यक क्रियाओं को करने वाली संज्ञाओं को बनाकर समस्या से बच रहा हूं। ऐसा करना बेहतर क्यों होगा? इसके लिए एक अच्छा कारण होना चाहिए , कुछ मैं एक व्यावहारिक उदाहरण के रूप में मात्रा निर्धारित कर सकता हूं।
मैट एश

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

पैटिंग संसाधन बहुत अच्छा है।
वायट बार्नेट

2

ऐसी भाषा पर विचार करें जहां सभी निर्माण (जैसे कार्य) ऑब्जेक्ट हैं। तब Restful verbs केवल सम्मेलनों और असाइनमेंट स्टेटमेंट्स को बुला रहे हैं। जावास्क्रिप्ट के लिए आप एक फ़ंक्शन को कॉल करने के लिए INVOKE जैसे एक निश्चित क्रिया सिंटैक्स को परिभाषित कर सकते हैं, DELETE (उसी तरह js में हटाएं) किसी ऑब्जेक्ट को किसी ऑब्जेक्ट को हटाने के लिए, एक मान निर्दिष्ट करने के लिए सेट और एक मान वापस करने के लिए RETURN। हम बराबर POST - invoke function, PUT - असाइन मूल्य, GET - एक मान लौटाएँ, - DELETE - किसी ऑब्जेक्ट को हटाने के लिए HTTP क्रियाओं का उपयोग कर सकते हैं। मैं इस विचार में फंस गया था कि HTTP तरीके वास्तव में ऑब्जेक्ट मेथड्स, वास्तविक ऑब्जेक्ट इंटरफेस का वर्णन कर रहे थे, जो कि मैं यह देखने में विफल रहा कि यह वास्तव में बहुत निचले स्तर की अवधारणाओं का वर्णन कर सकता है, जैसे कि मूल भाषा निर्माण जो स्पष्ट रूप से तय किए गए हैं और सभी में परिमित हैं समझदार भाषाएँ।

और निश्चित रूप से यह मार्ग के लिए सहायक है / परावर्तित करने के लिए एक निश्चित शब्दावली है।


1
  • क्योंकि एक पेशेवर प्रोग्रामर सैकड़ों का अनुमान लगाता है, यदि नहीं तो हजारों विधि नाम अन्यथा। छोटे से छोटे स्तर पर ऐसा लगता है कि आवेदन बहुत बड़ा हो सकता है।

  • क्योंकि पहले से ही परिभाषित होने पर विधि के नामों के बारे में मानकों की कोई आवश्यकता नहीं है।

  • क्योंकि ऐसे अतिरिक्त अनुवादों के बिना कोड का मुख्य उद्देश्य पठनीय है।

  • क्योंकि यह 'जब' की पहचान को प्रोत्साहित करता है और एक और वर्ग को तोड़ दिया जाना चाहिए।

  • जब आप कोड लेते हैं तो यह उचित है और वास्तव में यह समझना संभव है कि यह क्या और कैसे करता है यह बहुत तेज है।

  • यह एक सामान्य शब्दावली और इस प्रकार अमूर्तता का स्तर प्रदान करता है ताकि आप अन्य विवरणों पर ध्यान केंद्रित कर सकें और पैटर्न देख सकें।

  • यह सामान्य कोड के रूप में बग को आसान बनाता है और दृष्टिकोणों को आसानी से जांचा जा सकता है।

  • जब आप वेब डेवलपमेंट में कई 'लेयर्स' के साथ काम कर रहे होते हैं, तो यह जानते हुए कि डिबगिंग के लिए एक्शन नामों का मिलान किस क्रिया से होता है।

कुल मिलाकर आपको इसकी हमेशा आवश्यकता नहीं है, लेकिन अधिकांश मानकों की तरह, इसका उपयोग करने का प्रयास करने के लिए बहुत मायने रखता है!


क्रम 1 में जोड़ा गया) तो एक प्रोग्रामर सैकड़ों का अनुमान लगाता है यदि हजारों संसाधन नहीं तो? हम अपने द्वारा उपयोग किए जाने वाले पुस्तकालयों में पहले से ही तरीकों का अनुमान लगाते हैं। 2) इसलिए हमें विधि नामों के लिए मानकों की आवश्यकता है लेकिन संसाधन नामों के लिए नहीं? मैं उस तर्क को विफल करने में विफल रहा। 3) अनुवादों से आपका क्या मतलब है, यह निश्चित नहीं है। यदि आप मुझे बताएं कि एक संसाधन मौजूद है तो मुझे इसे समझना होगा। अगर मैं आपको एक तरीका बताता हूं तो आपको इसे समझना होगा। केवल एक चीज जिसकी मैं वास्तव में परवाह करता हूं कि मेरे कार्यों में से कौन से दुष्प्रभाव होंगे 4) क्या आप विस्तार कर सकते हैं
मैट एश

5) फिर से आप विस्तार कर सकते हैं। मैं एक प्रोग्रामर हूं। मुझे अच्छी तरह से परिभाषित ऑब्जेक्ट संरचनाओं के साथ काम करने की आदत है। अगर हम वास्तव में कोई बेहतर हैं तो हम अपने सभी एपीआई को परिभाषित करने के लिए इसी तंत्र का उपयोग क्यों नहीं करेंगे? 6) अमूर्तता का कोई स्तर औचित्य के बिना विचार करने लायक नहीं है 7) फिर से आप विस्तार कर सकते हैं। यदि हम इस तरह से लाभान्वित होते हैं तो निश्चित रूप से हमें अपने सभी एपीआई को इस तरह से कोडित करना चाहिए। ) मैं किसी भी वस्तु की अपेक्षा करूँगा कि वह इसके तरीकों को सीधे उजागर करे। / ऑब्जेक्ट / विधि को भ्रमित नहीं किया जा सकता है। हम उन्हें अपनाने के लिए चुनकर मानकों को परिभाषित करते हैं। मुझे इस समय प्रेरणा की कमी है।
मैट एश

मैट आपको थोड़ा तर्कपूर्ण लगता है, लेकिन मैं कहूंगा कि 2 के लिए) मैंने यह नहीं कहा कि संसाधन को मानकों की आवश्यकता नहीं होगी 3) आपको 'अपडेट' या 'नया' या 'बनाने' जैसी विधि को समझने की आवश्यकता नहीं होगी क्योंकि आप जानते हैं कि वास्तव में मानकों के अनुसार वे क्या करते हैं। हालाँकि 'MsgToPrimary' के बारे में क्या करता है? एक संदेश बनाएँ? स्थिति अपडेट करें? एक ईमेल भेजो? 7) हाँ अधिकांश एपीआई को इससे लाभ मिल सकता है और कई करते हैं। मैं धारणा मानक मानकों पर ध्यान केंद्रित करने की कोशिश करूंगा और कन्वेंशन सहायक हैं और मैं देख सकता हूं कि आपके अपडेट यह दिखा रहे हैं।
माइकल डुरंट

मैं सिर्फ फायदों को समझने की कोशिश कर रहा हूं। समस्या को स्पष्ट करने के लिए मजबूत प्रतिवाद को संबोधित करने की आवश्यकता है। फिर भी मैं समझता हूं कि क्रियाओं का एक निश्चित सेट एक भाषा विवरण की तरह है, लेकिन मैं वास्तव में सहमत नहीं हूं कि यह समझने में आसान बनाता है। आप क्रियाओं का एक अभिव्यंजक सेट नहीं निकाल सकते हैं और कहते हैं कि हम अब सभी क्रियाओं को समझते हैं, जब हम सभी संसाधनों को नहीं समझते हैं। संसाधन क्रियाओं की जगह ले रहे हैं। हम मनमाने ढंग से क्रिया foo को foo नामक संसाधन से बदलते हैं। फू की हमारी समझ इससे अधिक स्पष्ट नहीं है जब यह एक क्रिया थी।
मैट एश

1

वैकल्पिक कुछ भयानक है: डब्ल्यूएसडीएल (उर्फ वेब सर्विस डेफिनिशन लैंग्वेज), जो प्रोग्रामिक रूप से (कुछ हद तक) मनमाने ढंग से एपीआईएस का वर्णन करने के लिए एक (अनाड़ी) तरीका है।

REST गंभीर रूप से क्रियाओं को सीमित करता है, दस्तावेज़ के पेलोड में लगभग सभी अनुप्रयोग-विशिष्ट भिन्नता को धकेलता है। ऐसा करने का लाभ यह है कि कई ग्राहक कार्यान्वयन कई विषम सेवाओं के साथ संवाद कर सकते हैं। क्लाइंट और सर्वर एक दूसरे के लिए पूरी तरह से अज्ञात हो सकते हैं, कुछ अभी तक नहीं लिखे जा रहे हैं।

एक पॉडकास्ट है जिसमें स्टीफन टिलकोव ने रेस्ट को अच्छी तरह से समझाया


1

हाँ, बाकी एपीआई में क्रियाओं का एक निश्चित सेट है, लेकिन इसे सीमित (या GET, POST, PUT, DELETE) तक सीमित नहीं करना है। मैं GEST, POST, PUT, DELETE को REST के एक डिफ़ॉल्ट कार्यान्वयन के रूप में देखूंगा जो वहां से सभी प्रणालियों के 80% के लिए काम करता है।

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

किशोर सामाजिक नेटवर्क, Piczo.com, (यह शांति से आराम कर सकता है) में एक विस्तारित REST एपीआई (ऊपर उल्लिखित क्रियाओं सहित) को 7 विभिन्न भाषाओं में लागू किया गया था!


0

सरल अच्छा है।

ऐसे मामले होते हैं जब आपको अतिरिक्त क्रियाओं और जटिलता की आवश्यकता होती है, लेकिन अधिकांश समस्याओं को संसाधनों पर सरल सीआरयूडी कार्यों के लिए ट्रिम किया जा सकता है, और यही REST को बढ़ावा देने की कोशिश करता है। जब आप अधिकांश वेब अनुप्रयोगों के बारे में सोचते हैं, तो अंत में वे एक डेटा स्टोर में रिकॉर्ड पढ़ते हैं और जारी रखते हैं, जो समान सरल कार्यों का उपयोग करते हैं।

object.foo () सब अच्छा है, लेकिन यह क्या करता है? यह क्या लौट रहा है? क्या यह वस्तु की स्थिति या उसकी किसी भी निर्भरता को संशोधित कर रहा है? क्या आप इसे दो बार कॉल कर सकते हैं और एक ही परिणाम प्राप्त कर सकते हैं या यह आपको दो अलग-अलग मूल्य देने जा रहा है? यदि आपके पास ऑब्जेक्ट.बार () भी है, तो क्या उन्हें एक विशिष्ट क्रम में बुलाया जाना चाहिए?

एक समृद्ध एपीआई का उपयोग करने के लिए बहुत सारे ज्ञान की आवश्यकता होती है, और उनके पास आमतौर पर अपने स्वयं के सम्मेलन होते हैं (यानी सेटफू ऑब्जेक्ट को म्यूट करने के लिए जा रहा है, गेटबार शायद बेरोजगार है, निपटाना () या नष्ट () का मतलब है कि एक ही वस्तु पर कोई अन्य कॉल नहीं संभव होगा, आदि ...)

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