Desafortunadamente, Connection ya tiene el acceso options por lo que no podemos reutilizarlo para realizar una solicitud de OPCIONES. Tendrás que usar run_request(:options)

Quizás sea una suposición ingenua, pero ¿no sería más fácil reasignar :options a, no sé, :configuration , en lugar de tener un patrón de uso diferente?

No quiero cambiar una API establecida para admitir un HTTP que rara vez se usa
método al que se puede acceder fácilmente a través de run_request .

En mi humilde opinión, esta decisión debería reconsiderarse. OPTIONS es un nombre de método HTTP válido y run_request no siempre es una alternativa adecuada. Si vamos a romper la API pública, es mejor hacerlo ahora, antes de lanzar 1.0, que lamentar la decisión más tarde.

¿Por qué run_request no siempre es una alternativa adecuada?

Para los autores de bibliotecas de nivel inferior que se basan en Faraday, lo haría
en realidad recomiendo usar run_request sobre los métodos get , post .

@mislav #run_request no toma un bloque, como #get , #post , etc. Eche un vistazo a cómo estoy usando Faraday en Twitter::REST::Client#request : https://github.com/sferik/twitter/blob/master/lib/twitter/rest/client.rb#L130 -L144

run_request no toma un bloque, como #get, #post, etc.

¿Qué te hace pensar eso ?

Su caso de uso es un ejemplo perfecto de cuándo usar run_request , es decir, para evitar send .

Ahora recuerdo por qué no me gusta #run_request . De hecho, lo estaba usando en un punto del código Twitter::Client#request , pero lo eliminé como parte de una refactorización: https://github.com/sferik/twitter/commit/2d70b64674bdc204c85c47327afa571f9641e545. Creo que debes admitir que el código es mucho más limpio con #send (desearía que este no fuera el caso).

Con #run_request , tuve que preocuparme por si la solicitud era PUT o POST y establecer el cuerpo de la solicitud frente a los parámetros de consulta para GET , DELETE , etc. Con los métodos verbales, simplemente puedo pasarles un hash y ellos saben cómo manejarlo correctamente. En mi humilde opinión, esta es una interfaz mucho más amigable que con #run_request .

Lo desafiaría a enviar una solicitud de extracción a la gema twitter que reemplaza #send con #run_request que da como resultado un código menos complejo (de acuerdo con Code Climate o algún otro análisis estático ).

En defensa del método OPTIONS , es muy difícil adivinar la popularidad futura de los verbos HTTP. En HTTP 1.0, solo había GET y POST. En 1999, se agregaron más verbos en HTTP 1.1, pero en su mayoría se ignoraron hasta que Rails 2 agregó soporte para PUT y DELETE en rutas de recursos. Ahora, en Rails 4, PATCH se admite junto con PUT . Hace unos años, es posible que haya afirmado (correctamente) que “ PATCH no es muy popular” y, por lo tanto, no requiere un soporte de primera clase. Hoy en día, todos los servidores API nuevos escritos en Rails admiten PATCH , incluida la API de GitHub , que admitía PATCH antes del lanzamiento de Rails 4. La API de GitHub también admite OPTIONS para el intercambio de recursos de origen cruzado (CORS). Es posible que este uso de OPTIONS aún no sea popular, pero se volverá popular casi de la noche a la mañana si se agrega CORS por defecto en Rails 5. Si esto sucede, creo que se arrepentirá de haber ignorado este problema.

Los verbos HTTP son palabras reservadas importantes para una biblioteca HTTP. Hay solo algunos de ellos y, en mi opinión, deberíamos apoyarlos a todos como ciudadanos de primera clase en Faraday 1.0, incluso si eso significa romper cosas en el camino.

CORS es un caso de uso muy importante. Me decepcionaría si 1.0 se envía sin OPTIONS como verbo de primera clase.

Lamento mucho _bump_ esto, pero ¿algún acuerdo sobre el apoyo de options como método para las solicitudes OPTIONS ? Estaría más que feliz de enviar una solicitud de extracción para que esto suceda.

Todavía no estoy convencido de la idea. ¿Cómo se llamaría entonces al método actual options ?

Otros métodos que admitimos son los verbos: obtener, publicar, poner, eliminar. Facilita la comprensión de que se está produciendo alguna acción cuando los llama. options no sería un verbo y, como tal, no creo que sea un buen método abreviado. Si las personas están usando OPTIONS por tonelada en el código diario y no pueden soportar usar run_request por alguna razón (¡me gustaría escuchar esa razón!), Entonces sugeriría nombrando el nuevo método http_options para indicar que se trata de un método de solicitud HTTP.

El argumento de "los otros métodos son verbos" no debería importar. No son métodos en Faraday porque son verbos, esos métodos existen porque son métodos HTTP. Lo mismo debería suceder para options IMO.

Si esta es la razón para no tener options , entonces head no debería definirse, ya que "head" en HTTP no se trata de "going", el verbo.

Me preocupa totalmente romper la API con options , pero es una gran sorpresa que no sea "compatible". Es mucho más consistente tener todos los métodos HTTP manejados de la misma manera.

Y sobre no usar run_request , como se señaló antes, el código sin él es mucho más limpio.

Sigue siendo tu decisión (obviamente :-)) decidir si apoyar esto o no, pero me encantaría cambiar de opinión al respecto, y si no va a ser compatible, es para otra cosa que no sea "_options_ un verbo".

+1 @nhocki

Esto me tomó por sorpresa hoy. Todos los ejemplos con conn.get , conn.post , conn.delete etc. me llevan a creer que la forma obvia de hacer una solicitud de OPCIONES era conn.options .

Tal vez podríamos documentar esta inconsistencia y su run_request solución en los Faraday::Connection rdocs o el README? Me complace redactar una solicitud de extracción.

+1

¿Por qué las opciones no son las mismas que GET, POST, DELETE?

Aunque personalmente estoy de acuerdo con @mislav , no puedo ignorar la opinión de @sferik y los comentarios de la comunidad. Revisé el código y noté que options es simplemente un attr_reader , además de que lo utilizan principalmente las pruebas.
Sin embargo, estamos hablando de una API pública que podría interrumpir el cambio de algunas implementaciones, por lo que esto se abordará solo en Faraday 1.0.
Hasta entonces, feliz de volver a discutir esto si alguien está en contra.

Creo que conn.options debería ser totalmente una cosa. Su existencia depende en gran medida de la existencia de conn.get , conn.post , etc. Pero dado que rompería la compatibilidad con versiones anteriores, la v1.0 parece un buen objetivo para poner esto.

¡Buenas noticias para todos! Implementé esto sobrecargando #options para admitir el nuevo comportamiento, mientras mantenía el comportamiento existente. https://github.com/lostisland/faraday/pull/857