दुर्भाग्य से, कनेक्शन में पहले से ही options एक्सेसर है, इसलिए हम विकल्प अनुरोध करने के लिए इसका पुन: उपयोग नहीं कर सकते। आपको run_request(:options) का उपयोग करना होगा

शायद यह एक भोली धारणा है, लेकिन एक अलग उपयोग पैटर्न के बजाय :options को, मुझे पता नहीं, :configuration को रीमैप करना आसान नहीं होगा?

मैं शायद ही कभी इस्तेमाल किए जाने वाले HTTP का समर्थन करने के लिए एक स्थापित एपीआई को बदलना नहीं चाहता हूं
विधि जो run_request माध्यम से आसानी से सुलभ है।

IMHO, इस निर्णय पर पुनर्विचार किया जाना चाहिए। OPTIONS एक मान्य HTTP विधि नाम है और run_request हमेशा एक उपयुक्त विकल्प नहीं होता है। यदि हम सार्वजनिक एपीआई को तोड़ने जा रहे हैं, तो बाद में निर्णय पर पछताने के बजाय, 1.0 जारी करने से पहले इसे अभी करना बेहतर है।

run_request हमेशा एक उपयुक्त विकल्प क्यों नहीं है?

निचले स्तर के पुस्तकालय लेखकों के लिए जो फैराडे के शीर्ष पर निर्मित होते हैं, मैं
वास्तव में run_request से अधिक get , post विधियों का उपयोग करने की सलाह देते हैं।

@mislav #run_request कोई ब्लॉक नहीं लेता है, जैसे #get , #post , आदि। इस पर एक नज़र डालें कि मैं Twitter::REST::Client#request में फैराडे का उपयोग कैसे कर रहा हूं: https://github.com/sferik/twitter/blob/master/lib/twitter/rest/client.rb#L130 -L144

run_request कोई ब्लॉक नहीं लेता है, जैसे #get, #post, आदि।

आपको ऐसा क्या लगता है ?

run_request का उपयोग करते समय आपका उपयोग मामला एक आदर्श उदाहरण है, अर्थात send से बचने के लिए।

अब मुझे याद है कि मुझे #run_request क्यों पसंद नहीं है। मैं वास्तव में इसे Twitter::Client#request कोड में एक बिंदु पर उपयोग कर रहा था, लेकिन इसे एक रिफैक्टरिंग के हिस्से के रूप में हटा दिया: https://github.com/sferik/twitter/commit/2d70b64674bdc204c85c47327afa571f9641e545। मुझे लगता है कि आपको स्वीकार करना होगा, कोड #send साथ बहुत साफ है (काश ऐसा नहीं होता)।

#run_request , मुझे इस बारे में चिंता करनी पड़ी कि क्या अनुरोध PUT या POST और GET , DELETE लिए अनुरोध बॉडी बनाम क्वेरी पैराम्स सेट करें। #run_request तुलना में बहुत अधिक मित्रवत इंटरफ़ेस है।

मैं आपको twitter मणि के लिए एक पुल अनुरोध सबमिट करने के लिए चुनौती #send को #run_request जिसके परिणामस्वरूप कम जटिल कोड होता है (कोड जलवायु या कुछ अन्य स्थिर विश्लेषण के अनुसार) )

OPTIONS पद्धति के बचाव में, HTTP क्रियाओं की भविष्य की लोकप्रियता का अनुमान लगाना बहुत कठिन है। HTTP 1.0 में, केवल GET और POST था। 1999 में, HTTP 1.1 में और क्रियाएँ जोड़ी गईं, लेकिन जब तक रेल्स 2 ने संसाधन मार्गों में PUT और DELETE लिए समर्थन नहीं जोड़ा, तब तक उन्हें अधिकतर अनदेखा कर दिया गया। अब, रेल 4 में, PATCH साथ PUT समर्थित है। कुछ साल पहले, आपने (सही ढंग से) दावा किया होगा कि " PATCH बहुत लोकप्रिय नहीं है" और इसलिए प्रथम श्रेणी के समर्थन की आवश्यकता नहीं है। आज, रेल में लिखे गए सभी नए एपीआई सर्वर PATCH समर्थन करते हैं, जिसमें गिटहब एपीआई भी शामिल है , जो रेल 4 जारी होने से पहले PATCH का समर्थन करता था। GitHub API क्रॉस ओरिजिनल रिसोर्स शेयरिंग (CORS) के लिए OPTIONS का भी समर्थन करता है। OPTIONS का यह उपयोग अभी तक लोकप्रिय नहीं हो सकता है, लेकिन यह लगभग रातोंरात लोकप्रिय हो जाएगा यदि CORS को रेल 5 में डिफ़ॉल्ट के रूप में जोड़ा जाता है। यदि ऐसा होता है, तो मुझे लगता है कि आपको इस मुद्दे को दूर करने के लिए खेद होगा।

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

CORS एक बहुत ही महत्वपूर्ण उपयोग मामला है। प्रथम श्रेणी क्रिया के रूप में विकल्प के बिना 1.0 जहाजों पर मुझे निराशा होगी।

मुझे _bump_ के लिए बहुत खेद है, लेकिन options को OPTIONS अनुरोधों के लिए एक विधि के रूप में समर्थन करने पर कोई समझौता? मुझे ऐसा करने के लिए एक पुल अनुरोध सबमिट करने में बहुत खुशी होगी।

मैं अभी भी इस विचार पर नहीं बिका हूं। तब वर्तमान options पद्धति को क्या कहा जाएगा?

अन्य विधियाँ जिनका हम समर्थन करते हैं, वे हैं क्रियाएँ: प्राप्त करें, पोस्ट करें, डालें, हटाएं। इससे यह समझना आसान हो जाता है कि जब आप उन्हें कॉल करते हैं तो कुछ क्रिया हो रही होती है। options एक क्रिया नहीं होगी और OPTIONS प्रति टन का उपयोग कर रहे हैं और किसी कारण से run_request का उपयोग नहीं कर सकते हैं (मैं उस कारण को सुनना चाहता हूं!) तो मैं सुझाव दूंगा नई विधि http_options का नामकरण यह इंगित करने के लिए कि यह एक HTTP अनुरोध विधि है।

"अन्य विधियां क्रिया हैं" का तर्क मायने नहीं रखना चाहिए। वे फैराडे में विधियाँ नहीं हैं क्योंकि वे क्रिया हैं, वे विधियाँ मौजूद हैं क्योंकि वे HTTP विधियाँ हैं। options IMO के लिए भी ऐसा ही होना चाहिए।

यदि यह options नहीं होने का कारण है, तो head को परिभाषित नहीं किया जाना चाहिए, क्योंकि HTTP में "हेड" क्रिया "गोइंग" के बारे में नहीं है।

मुझे पूरी तरह से एपीआई को options साथ तोड़ने की चिंता है, लेकिन यह एक बड़ा आश्चर्य है कि यह "समर्थित" नहीं है। सभी HTTP विधियों को समान रूप से संभालने के लिए यह अधिक सुसंगत है।

और run_request का उपयोग न करने के बारे में, जैसा कि पहले बताया गया था, इसके बिना कोड बहुत अधिक साफ है।

यह अभी भी आपकी कॉल है (जाहिर है :-)) इसका समर्थन करने का निर्णय लेने के लिए, लेकिन मुझे इसके बारे में आपका विचार बदलना अच्छा लगेगा, और यदि यह समर्थित नहीं होने वाला है, तो यह "_options_ नहीं है" के अलावा किसी और चीज़ के लिए है एक क्रिया"।

+1 @nhoki

इसने मुझे आज चौंका दिया। conn.get , conn.post , conn.delete आदि के साथ सभी उदाहरण मुझे विश्वास दिलाते हैं कि एक विकल्प अनुरोध करने का स्पष्ट तरीका conn.options ।

शायद हम इस असंगति और इसके run_request वर्कअराउंड को Faraday::Connection rdocs या README में प्रलेखित कर सकते हैं? मुझे एक पुल अनुरोध लिखने में खुशी हो रही है।

+1

विकल्प GET, POST, DELETE के समान क्यों नहीं हैं?

भले ही मैं व्यक्तिगत रूप से @mislav से सहमत @sferik राय और समुदाय प्रतिक्रिया को अनदेखा नहीं कर सकता। मैंने कोड की जांच की और देखा कि options बस एक attr_reader , साथ ही इसका उपयोग मुख्य रूप से परीक्षणों द्वारा किया जा रहा है।
हालांकि, हम एक सार्वजनिक एपीआई के बारे में बात कर रहे हैं जो संभावित रूप से बदले जा रहे कुछ कार्यान्वयन को तोड़ सकता है, इसलिए इसे केवल फैराडे 1.0 में संबोधित किया जाएगा
तब तक, अगर कोई इसके खिलाफ है तो इस पर फिर से चर्चा करने में खुशी होगी

मुझे लगता है कि conn.options पूरी तरह से एक चीज होनी चाहिए। इसका अस्तित्व conn.get , conn.post , आदि के अस्तित्व से बहुत अधिक है। लेकिन चूंकि यह पश्चगामी संगतता को तोड़ देगा, v1.0 इसे लगाने के लिए एक अच्छे लक्ष्य की तरह लगता है।

सबके लिए अच्छी खबर है! मैंने मौजूदा व्यवहार को बनाए रखते हुए, नए व्यवहार का समर्थन करने के लिए #options को ओवरलोड करके इसे लागू किया। https://github.com/lostisland/faraday/pull/857