К сожалению, в Connection уже есть аксессор options поэтому мы не можем использовать его для выполнения запроса OPTIONS. Вам нужно будет использовать run_request(:options)

Возможно, это наивное предположение, но не проще ли было бы переназначить :options на :configuration , не знаю, вместо того, чтобы иметь другой шаблон использования?

Я не хочу менять установленный API для поддержки редко используемого HTTP
метод, который легко доступен через run_request .

ИМХО, это решение надо пересмотреть. OPTIONS - допустимое имя метода HTTP, а run_request не всегда является подходящей альтернативой. Если мы собираемся сломать публичный API, лучше сделать это сейчас, до выпуска 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 что приводит к менее сложному коду (согласно Code Climate или другому статическому анализу ).

В защиту метода OPTIONS очень трудно предсказать будущую популярность HTTP-глаголов. В HTTP 1.0 были только GET и POST. В 1999 году в HTTP 1.1 было добавлено больше глаголов, но они по большей части игнорировались, пока Rails 2 не добавил поддержку PUT и DELETE в маршрутах ресурсов. Теперь в Rails 4 PATCH поддерживается наряду с PUT . Несколько лет назад вы могли (правильно) заявить, что « PATCH не очень популярен» и, следовательно, не требует первоклассной поддержки. Сегодня все новые серверы API, написанные на Rails, поддерживают PATCH , включая GitHub API , который поддерживал PATCH до выпуска Rails 4. GitHub API также поддерживает OPTIONS для совместного использования ресурсов Cross Origin (CORS). Такое использование OPTIONS возможно, пока не пользуется популярностью, но оно станет популярным почти в мгновение ока, если CORS будет добавлен по умолчанию в Rails 5. Если это произойдет, я думаю, вы пожалеете, что отмахнулись от этой проблемы.

Глаголы HTTP - важные зарезервированные слова для библиотеки HTTP. Их всего несколько, и, на мой взгляд, мы должны поддержать их всех как первоклассных граждан в Faraday 1.0, даже если это означает, что по пути что-то сломается.

CORS - очень важный вариант использования. Я был бы разочарован, если 1.0 выйдет без OPTIONS в качестве первоклассного глагола.

Мне ужасно жаль, что _bump_ это, но есть ли какое-либо соглашение о поддержке options как метода для OPTIONS запросов? Я был бы более чем счастлив отправить запрос на перенос, чтобы это произошло.

Я все еще не согласен с этой идеей. Как тогда будет вызван текущий метод options ?

Другие методы, которые мы поддерживаем, - это глаголы: получить, опубликовать, поместить, удалить. Это позволяет легко понять, что когда вы их вызываете, происходит какое-то действие. options не было бы глаголом, и поэтому я не думаю, что это будет хороший сокращенный метод. Если люди используют OPTIONS за тонну в повседневном коде и по какой-то причине не могут использовать run_request (я бы хотел услышать эту причину!), То я бы посоветовал присвоение имени новому методу http_options чтобы указать, что это метод HTTP-запроса.

Аргумент «другие методы - глаголы» не имеет значения. Они не являются методами по Фарадею, потому что они глаголы, эти методы существуют, потому что они являются методами HTTP. То же самое должно произойти для options IMO.

Если это причина отсутствия options , тогда head не следует определять, поскольку "head" в HTTP не означает "идти", глагол.

Меня полностью беспокоит нарушение API с помощью options , но очень удивительно, что он не "поддерживается". Гораздо более согласованно, чтобы все методы HTTP обрабатывались одинаково.

А насчет того, чтобы не использовать run_request , как было указано ранее, код без этого намного чище.

Это все еще ваш призыв (очевидно :-)) - решать, поддерживать это или нет, но я бы хотел изменить ваше мнение по этому поводу, и если он не будет поддерживаться, то это для чего-то другого, кроме "_options_ is not глагол".

+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, который потенциально может нарушить работу некоторых изменяемых реализаций, поэтому этот вопрос будет решен только в Faraday 1.0.
А пока буду рад обсудить это повторно, если кто-то против.

Я думаю, что conn.options должно быть абсолютно правильным. Его существование в значительной степени зависит от наличия conn.get , conn.post и т. Д. Но поскольку это нарушит обратную совместимость, версия 1.0 звучит как хорошая цель для этого.

Хорошие новости всем! Я реализовал это путем перегрузки #options для поддержки нового поведения при сохранении существующего поведения. https://github.com/lostisland/faraday/pull/857