لسوء الحظ ، يحتوي Connection بالفعل على options لذا لا يمكننا إعادة استخدامه لتقديم طلب OPTIONS. يجب عليك استخدام run_request(:options)

ربما يكون هذا افتراضًا ساذجًا ، لكن ألن يكون من الأسهل إعادة تعيين :options to ، لا أعرف ، :configuration ، بدلاً من استخدام نمط استخدام مختلف؟

لا أريد تغيير واجهة برمجة التطبيقات المنشأة لدعم HTTP نادر الاستخدام
الطريقة التي يمكن الوصول إليها بسهولة من خلال run_request .

IMHO ، ينبغي إعادة النظر في هذا القرار. OPTIONS هو اسم طريقة HTTP صالح و run_request ليس دائمًا بديلًا مناسبًا. إذا كنا سنكسر واجهة برمجة التطبيقات العامة ، فمن الأفضل القيام بذلك الآن ، قبل إصدار 1.0 ، بدلاً من الأسف على القرار لاحقًا.

لماذا لا يكون run_request دائمًا بديلاً مناسبًا؟

بالنسبة لمؤلفي المكتبات من المستوى الأدنى الذين يعتمدون على فاراداي ، سأفعل ذلك
نوصي باستخدام طرق run_request أكثر من get ، post .

mislav #run_request لا يأخذ كتلة ، مثل #get ، #post ، إلخ. ألق نظرة على كيفية استخدامي Faraday في 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 ، إلخ. باستخدام طرق الفعل ، يمكنني ببساطة تمرير علامة التجزئة إليهم وهم يعرفون كيفية التعامل معها بشكل صحيح. IMHO ، هذه واجهة أكثر ودية من واجهة #run_request .

أود أن أتحداك أن ترسل طلب سحب إلى twitter جوهرة التي تحل محل #send بـ #run_request الذي ينتج عنه كود أقل تعقيدًا (وفقًا لـ Code Climate أو بعض التحليلات الثابتة الأخرى ).

دفاعًا عن طريقة OPTIONS ، من الصعب جدًا تخمين الشعبية المستقبلية لأفعال HTTP. في HTTP 1.0 ، لم يكن هناك سوى GET و POST. في 1999 ، تمت إضافة المزيد من الأفعال في HTTP 1.1 ، ولكن تم تجاهلها في الغالب حتى أضاف ريلز 2 دعمًا لـ PUT و DELETE في مسارات الموارد. الآن ، في ريلز 4 ، يتم دعم PATCH بجانب PUT . قبل بضع سنوات ، ربما زعمت (بشكل صحيح) أن " PATCH ليس مشهورًا جدًا" وبالتالي لا يتطلب دعمًا من الدرجة الأولى. اليوم ، تدعم جميع خوادم API الجديدة المكتوبة في Rails PATCH ، بما في ذلك GitHub API ، التي دعمت PATCH قبل إصدار Rails 4. تدعم واجهة برمجة تطبيقات GitHub أيضًا OPTIONS لمشاركة الموارد عبر الأصول (CORS). قد لا يكون استخدام هذا OPTIONS شائعًا حتى الآن ، لكنه سيصبح شائعًا بين عشية وضحاها تقريبًا إذا تمت إضافة CORS كإعداد افتراضي في Rails 5. إذا حدث هذا ، أعتقد أنك ستندم على تجاهل هذه المشكلة.

أفعال HTTP هي كلمات محجوزة مهمة لمكتبة HTTP. لا يوجد سوى عدد قليل منهم وفي رأيي ، يجب أن ندعمهم جميعًا كمواطنين من الدرجة الأولى في Faraday 1.0 ، حتى لو كان ذلك يعني كسر الأشياء على طول الطريق.

CORS هي حالة استخدام مهمة جدًا. سأصاب بخيبة أمل إذا تم شحن 1.0 بدون OPTIONS كفعل من الدرجة الأولى.

أنا آسف بشدة لـ _bump_ هذا ، ولكن هل هناك أي اتفاق على دعم options كطريقة لطلبات OPTIONS ؟ يسعدني جدًا إرسال طلب سحب لتحقيق ذلك.

ما زلت غير مقتنع بالفكرة. ماذا سيطلق على طريقة options بعد ذلك؟

الطرق الأخرى التي ندعمها هي الأفعال: get ، post ، put ، delete. يجعل من السهل فهم أن بعض الإجراءات تحدث عندما تتصل بهم. لن يكون options فعلًا وعلى هذا النحو لا أعتقد أنه سيكون طريقة اختزال لطيفة. إذا كان الأشخاص يستخدمون OPTIONS للطن في الكود اليومي ولا يمكنهم تحمل استخدام run_request لسبب ما (أود أن أسمع هذا السبب!) فأنا أقترح تسمية الطريقة الجديدة http_options للإشارة إلى أن هذه طريقة طلب HTTP.

حجة "الطرق الأخرى هي أفعال" لا ينبغي أن تكون مهمة. إنها ليست طرقًا في Faraday لأنها أفعال ، هذه الطريقة موجودة لأنها طرق HTTP. يجب أن يحدث نفس الشيء لـ options IMO.

إذا كان هذا هو سبب عدم وجود options ، فلا يجب تحديد head ، لأن "head" في HTTP لا تعني "Go" ، أي الفعل.

أشعر بالقلق تمامًا بشأن كسر واجهة برمجة التطبيقات options ، لكن المفاجأة الكبيرة هي أنها غير "مدعومة". إنها طريقة أكثر اتساقًا للتعامل مع جميع طرق HTTP بالطريقة نفسها.

وحول عدم استخدام run_request ، كما تم الإشارة إليه من قبل ، فإن الكود بدونه يكون أكثر نظافة.

لا تزال مكالمتك (من الواضح :-)) لتقرر دعم هذا أم لا ، لكني أود تغيير رأيك حيال ذلك ، وإذا لم يتم دعمه ، فهذا لشيء آخر غير "_ الخيارات_" فعل".

+1 @ nhocki

لقد فاجأني هذا اليوم. كل الأمثلة مع conn.get ، conn.post ، conn.delete إلخ. تقودني إلى الاعتقاد بأن الطريقة الواضحة لتنفيذ طلب OPTIONS هي conn.options .

ربما يمكننا توثيق هذا التناقض والحل البديل الخاص به run_request في Faraday::Connection rdocs أو README؟ يسعدني إنشاء طلب سحب.

+1

لماذا لا تكون الخيارات مثل GET و POST و DELETE؟

على الرغم من أنني أتفق شخصيًا مع mislav ، لا يمكنني تجاهل رأي sferik وتعليقات المجتمع. لقد تحققت من الكود ولاحظت أن options هو ببساطة attr_reader ، بالإضافة إلى أنه يتم استخدامه بشكل أساسي عن طريق الاختبارات.
ومع ذلك ، فإننا نتحدث عن واجهة برمجة تطبيقات عامة يمكن أن تعطل بعض عمليات التنفيذ التي يتم تغييرها ، وبالتالي سيتم تناول ذلك فقط في Faraday 1.0
حتى ذلك الحين ، يسعدني إعادة مناقشة هذا إذا كان أي شخص ضده

أعتقد أن conn.options يجب أن يكون شيئًا تمامًا. إن وجودها كثيف بسبب وجود conn.get ، conn.post ، إلخ. ولكن نظرًا لأنه سيؤدي إلى كسر التوافق مع الإصدارات السابقة ، يبدو v1.0 هدفًا جيدًا لوضع هذا فيه.

اخبارسعيدة يا جماعة! لقد نفذت هذا من خلال زيادة التحميل على #options لدعم السلوك الجديد ، مع الحفاظ على السلوك الحالي. https://github.com/lostisland/faraday/pull/857