残念ながら、Connectionにはすでにoptionsアクセサーがあるため、OPTIONSリクエストを行うために再利用することはできません。 run_request(:options)を使用する必要があります

おそらくそれは素朴な仮定ですが、異なる使用パターンを使用するよりも、 :optionsを:configurationに再マップする方が簡単ではないでしょうか。

確立されたAPIを変更して、めったに使用されないHTTPをサポートしたくない
run_requestから簡単にアクセスできるメソッド。

私見、この決定は再考されるべきです。 OPTIONSは有効なHTTPメソッド名であり、 run_requestが常に適切な代替手段であるとは限りません。 パブリックAPIを破壊する場合は、後で決定を後悔するよりも、1.0をリリースする前に今すぐ実行することをお勧めします。

run_requestが必ずしも適切な代替手段とは限らないのはなぜですか？

ファラデーの上に構築された低レベルのライブラリ作成者の場合、私は
実際には、 get 、 postメソッドよりもrun_requestを使用することをお勧めします。

@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 ： #sendはるかにきれいです（私はそうではなかったと思います）。

#run_requestを使用すると、リクエストがPUTかPOSTであるかを心配し、リクエストの本文とクエリパラメータをGET 、 DELETEなど。動詞メソッドを使用すると、ハッシュを渡すだけで、正しく処理する方法を知っています。 私見ですが、これは#run_requestよりもはるかに使いやすいインターフェースです。

#sendを#run_request置き換えるtwitter gemにプルリクエストを送信して、コードの複雑さを軽減するようにお願いします（Code Climateまたはその他の静的分析による） ）。

OPTIONSメソッドを守るために、HTTP動詞の将来の人気を推測するのは非常に困難です。 HTTP 1.0では、GETとPOSTしかありませんでした。 1999年にHTTP1.1で動詞が追加されましたが、Rails 2がリソースルートでPUTとDELETEサポートを追加するまで、ほとんど無視されていました。 現在、Rails 4では、 PATCHがPUTと一緒にサポートされています。 数年前、「 PATCHはあまり人気がない」と（正しく）主張したかもしれません。したがって、ファーストクラスのサポートは必要ありません。 現在、Rails 4がリリースされる前にPATCHをサポートしていたGitHub APIを含め、Railsで記述されたすべての新しいAPIサーバーはPATCHをサポートしています。 GitHub API OPTIONS 、クロスオリジンリソースシェアリング（CORS）のOPTIONS使用はまだ普及していない可能性がありますが、Rails 5にCORSがデフォルトとして追加されると、ほぼ一夜にして普及するでしょう。これが発生した場合、この問題を一掃したことを後悔すると思います。

HTTP動詞は、HTTPライブラリの重要な予約語です。 それらはほんのわずかであり、私の意見では、たとえそれが途中で物事を壊すことを意味するとしても、ファラデー1.0では一級市民としてそれらすべてをサポートする必要があります。

CORSは非常に重要なユースケースです。 1.0がファーストクラスの動詞としてOPTIONSなしで出荷されたら、私はがっかりするでしょう。

これを_バンプ_して大変申し訳ありませんが、 OPTIONSリクエストの方法としてoptionsをサポートすることに合意はありますか？ これを実現するために、プルリクエストを送信できれば幸いです。

私はまだその考えで売られていません。 その場合、現在のoptionsメソッドは何と呼ばれますか？

私たちがサポートする他のメソッドは動詞です：get、post、put、delete。 それらを呼び出すと、何らかのアクションが発生していることを簡単に理解できます。 optionsは動詞ではないので、それが良い速記法になるとは思いません。 人々が日常のコードで1トンのOPTIONSを使用していて、何らかの理由でrun_requestを使用することに耐えられない場合（その理由を聞きたいです！）、私は提案します新しいメソッドにhttp_optionsという名前を付けて、これがHTTPリクエストメソッドであることを示します。

「他のメソッドは動詞です」という議論は重要ではありません。 それらは動詞であるためファラデーのメソッドではなく、HTTPメソッドであるため存在します。 options IMOについても同じことが起こります。

これがoptionsを持たない理由である場合、HTTPの「head」は動詞の「going」ではないため、 headを定義しないでください。

optionsでAPIを壊すことについて完全に懸念を抱いていますが、それが「サポート」されていないことは大きな驚きです。 すべてのHTTPメソッドを同じように処理する方がはるかに一貫性があります。

そして、前に指摘したように、 run_requestを使用しないことについては、それがないコードははるかにクリーンです。

これをサポートするかどうかを決めるのはまだあなたの呼びかけです（明らかに:-)）、しかし私はそれについてあなたの考えを変えたいと思います、そしてそれがサポートされないのであれば、それは「_options_はそうではありません動詞"。

+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 、主にテストで使用されていることがわかりました。
ただし、変更されている一部の実装を壊す可能性のあるパブリックAPIについて話しているため、これはFaraday1.0でのみ対処されます。
それまでは、誰かがそれに反対している場合は、これについて再議論してください

conn.optionsは完全に問題になるはずだと思います。 その存在は、 conn.get 、 conn.postなどの存在に大きく依存します。しかし、下位互換性が損なわれるため、v1.0はこれを入れるのに適したターゲットのように思えます。

皆さん、朗報です！ これは、既存の動作を維持しながら、新しい動作をサポートするために#optionsをオーバーロードすることで実装しました。 https://github.com/lostisland/faraday/pull/857