Infelizmente, o Connection já tem o acessor options então não podemos redirecioná-lo para fazer uma solicitação OPTIONS. Você terá que usar run_request(:options)

Talvez seja uma suposição ingênua, mas não seria mais fácil remapear :options para, não sei, :configuration , em vez de ter um padrão de uso diferente?

Eu não quero mudar uma API estabelecida para suportar um HTTP raramente usado
método que é facilmente acessível por meio de run_request .

IMHO, esta decisão deve ser reconsiderada. OPTIONS é um nome de método HTTP válido e run_request nem sempre é uma alternativa adequada. Se vamos quebrar a API pública, é melhor fazer isso agora, antes de lançarmos 1.0, do que lamentar a decisão mais tarde.

Por que run_request nem sempre é uma alternativa adequada?

Para autores de bibliotecas de nível inferior que se baseiam no Faraday, eu gostaria
Na verdade, recomendo usar os métodos run_request vez de get , post .

@mislav #run_request não bloqueia, como #get , #post , etc. Dê uma olhada em como estou usando Faraday em Twitter::REST::Client#request : https://github.com/sferik/twitter/blob/master/lib/twitter/rest/client.rb#L130 -L144

run_request não leva um bloco, como #get, #post, etc.

O que te faz pensar assim ?

Seu caso de uso é um exemplo perfeito de quando usar run_request , ou seja, para evitar send .

Agora me lembro por que não gosto de #run_request . Na verdade, eu estava usando em um ponto do código Twitter::Client#request , mas o removi como parte de uma refatoração: https://github.com/sferik/twitter/commit/2d70b64674bdc204c85c47327afa571f9641e545. Acho que você deve admitir que o código é muito mais limpo com #send (gostaria que não fosse o caso).

Com #run_request , tive que me preocupar se a solicitação era PUT ou POST e definir o corpo da solicitação versus parâmetros de consulta para GET , DELETE , etc. Com os métodos verbais, posso simplesmente passar um hash para eles e eles saberão como lidar com isso corretamente. IMHO, esta é uma interface muito mais amigável do que com #run_request .

Eu o desafiaria a enviar uma solicitação pull para a gema twitter que substitui #send por #run_request que resulta em um código menos complexo (de acordo com o Code Climate ou alguma outra análise estática )

Em defesa do método OPTIONS , é muito difícil adivinhar a popularidade futura dos verbos HTTP. No HTTP 1.0, havia apenas GET e POST. Em 1999, mais verbos foram adicionados no HTTP 1.1, mas eles foram ignorados até que o Rails 2 adicionou suporte para PUT e DELETE em rotas de recursos. Agora, no Rails 4, PATCH é suportado junto com PUT . Alguns anos atrás, você pode ter afirmado (corretamente) que “ PATCH não é muito popular” e, portanto, não requer suporte de primeira classe. Hoje, todos os novos servidores API escritos em Rails suportam PATCH , incluindo a API GitHub , que suportava PATCH antes do Rails 4 ser lançado. A API GitHub também suporta OPTIONS para Cross Origin Resource Sharing (CORS). Este uso de OPTIONS pode não ser popular ainda, mas se tornará popular quase da noite para o dia se CORS for adicionado como padrão no Rails 5. Se isso acontecer, acho que você se arrependerá de não ter resolvido esse problema.

Os verbos HTTP são palavras reservadas importantes para uma biblioteca HTTP. Existem apenas alguns deles e, na minha opinião, devemos apoiá-los como cidadãos de primeira classe em Faraday 1.0, mesmo que isso signifique quebrar coisas ao longo do caminho.

CORS é um caso de uso muito importante. Eu ficaria desapontado se 1.0 fosse enviado sem OPTIONS como verbo de primeira classe.

Lamento _bump_ isto, mas há algum acordo em apoiar options como um método para OPTIONS solicitações? Eu ficaria mais do que feliz em enviar uma solicitação pull para que isso aconteça.

Ainda não estou convencido da ideia. Qual seria então o método options atual?

Outros métodos que oferecemos são os verbos: get, post, put, delete. Isso torna mais fácil entender que alguma ação está acontecendo quando você liga para eles. options não seria um verbo e, como tal, não acho que seria um bom método abreviado. Se as pessoas estão usando OPTIONS por tonelada no código do dia-a-dia e não suportam usar run_request por algum motivo (gostaria de ouvir esse motivo!), Então eu sugeriria nomeando o novo método http_options para indicar que este é um método de solicitação HTTP.

O argumento de "os outros métodos são verbos" não deveria importar. Eles não são métodos em Faraday porque são verbos, esses métodos existem porque são métodos HTTP. O mesmo deve acontecer com options IMO.

Se esta é a razão de não ter options , então head não deve ser definido, pois "cabeça" em HTTP não significa "ir", o verbo.

Percebo totalmente a preocupação de quebrar a API com options , mas é uma grande surpresa que ela não seja "suportada". É muito mais consistente ter todos os métodos HTTP tratados da mesma forma.

E sobre não usar run_request , como foi apontado antes, o código sem ele é muito mais limpo.

Ainda é sua decisão (obviamente :-)) decidir se apoiar ou não, mas eu adoraria mudar sua opinião sobre isso, e se não vai ser suportado, é por algo diferente de "_options_ não é um verbo".

+1 @nhocki

Isso me pegou de surpresa hoje. Todos os exemplos com conn.get , conn.post , conn.delete etc. me levam a acreditar que a maneira óbvia de fazer uma solicitação OPTIONS era conn.options .

Talvez pudéssemos documentar essa inconsistência e sua run_request solução alternativa no Faraday::Connection rdocs ou no README? Estou feliz em escrever um pedido de pull.

+1

Por que as opções não são iguais a GET, POST, DELETE?

Embora eu pessoalmente concorde com @mislav , não posso ignorar a opinião do @sferik e o feedback da comunidade. Eu verifiquei o código e percebi que options é simplesmente um attr_reader , além de estar sendo usado principalmente por testes.
No entanto, estamos falando sobre uma API pública que pode potencialmente quebrar algumas implementações que estão sendo alteradas, portanto, isso será abordado apenas no Faraday 1.0
Até então, fico feliz em voltar a discutir isso se alguém for contra

Eu acho que conn.options deveria ser totalmente uma coisa. Sua existência é fortemente pela existência de conn.get , conn.post , etc. Mas, uma vez que quebraria a compatibilidade com versões anteriores, a v1.0 soa como um bom alvo para colocar isso.

Boas notícias, pessoal! Eu implementei isso sobrecarregando #options para suportar o novo comportamento, enquanto mantenho o comportamento existente. https://github.com/lostisland/faraday/pull/857