不幸的是，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更友好的界面。

我会挑战您向twitter gem提交拉取请求，该#send替换#run_request ，从而减少复杂的代码（根据代码气候或其他一些静态分析） ）。

为OPTIONS方法辩护，很难猜测 HTTP 动词未来的流行程度。 在 HTTP 1.0 中，只有 GET 和 POST。 1999 年，HTTP 1.1 中添加了更多动词，但在 Rails 2 在资源路由中添加对PUT和DELETE支持之前，它们大多被忽略。 现在，在 Rails 4 中， PATCH与PUT一起被支持。 几年前，您可能（正确地）声称“ PATCH不是很受欢迎”，因此不需要一流的支持。 今天，所有用 Rails 编写的新 API 服务器都支持PATCH ，包括GitHub API ，它在 Rails 4 发布之前支持PATCH 。 GitHub API 还支持跨源资源共享 (CORS) 的OPTIONS 。 OPTIONS这种用法可能还不流行，但如果在 Rails 5 中默认添加 CORS，它几乎会在一夜之间流行。如果发生这种情况，我想你会后悔忽略这个问题。

HTTP 动词是 HTTP 库的重要保留字。 他们只有少数，在我看来，我们应该支持他们作为法拉第 1.0 中的一等公民，即使这意味着一路走来。

CORS 是一个非常重要的用例。 如果 1.0 没有将 OPTIONS 作为第一类动词发布，我会感到失望。

我非常抱歉 _bump_ 这个，但是关于支持options作为OPTIONS请求的方法的任何协议？ 我很乐意提交拉取请求来实现这一目标。

我仍然不相信这个想法。 那么当前的options方法会被调用什么？

我们支持的其他方法是动词：get、post、put、delete。 当您调用它们时，很容易理解某些操作正在发生。 options不是动词，因此我认为它不会成为一个很好的速记方法。 如果人们使用OPTIONS在一天到一天的代码一吨也舍不得用run_request出于某种原因（我很想听听这个原因！），那么我会建议将新方法命名为http_options以表明这是一个 HTTP 请求方法。

“其他方法是动词”的论点应该无关紧要。 它们不是法拉第中的方法，因为它们是动词，这些方法存在是因为它们是 HTTP 方法。 options IMO 也应该如此。

如果这是没有options ，则不应定义head ，因为 HTTP 中的“头”与动词“去”无关。

我完全担心用options破坏 API，但令人惊讶的是它不受“支持”。 让所有 HTTP 方法处理相同的方式更加一致。

关于不使用run_request ，就像之前指出的那样，没有它的代码要干净得多。

决定支持与否仍然是您的决定（显然 :-) ），但我很想改变您的想法，如果不支持，它是用于“_options_”以外的其他东西一个动词”。

+1 @nhocki

今天这让我很意外。 所有带有conn.get 、 conn.post 、 conn.delete等的例子让我相信执行 OPTIONS 请求的明显方法是conn.options 。

也许我们可以在Faraday::Connection rdocs 或自述文件中记录这种不一致及其run_request解决方法？ 我很高兴撰写拉取请求。

+1

为什么选项与 GET、POST、DELETE 不同？

尽管我个人同意@mislav ，但我不能忽视@sferik 的意见和社区反馈。 我检查了代码并注意到options只是一个attr_reader ，而且它主要用于测试。
然而，我们谈论的是一个公共 API，它可能会破坏一些正在更改的实现，因此这只会在 Faraday 1.0 中解决
在那之前，如果有人反对，很高兴重新讨论这个问题

我认为conn.options应该完全是一回事。 它的存在很大程度上取决于conn.get 、 conn.post等的存在。但是因为它会破坏向后兼容性，所以 v1.0 听起来是一个很好的目标。

好消息，大家！ 我通过重载#options来支持新行为，同时保持现有行为。 https://github.com/lostisland/faraday/pull/857