Malheureusement, Connection a déjà l'accesseur options , nous ne pouvons donc pas le réutiliser pour faire une requête OPTIONS. Vous devrez utiliser run_request(:options)

C'est peut-être une hypothèse naïve, mais ne serait-il pas plus facile de remapper :options vers, je ne sais pas, :configuration , plutôt que d'avoir un modèle d'utilisation différent ?

Je ne veux pas changer une API établie pour prendre en charge un HTTP rarement utilisé
méthode facilement accessible via run_request .

À mon humble avis, cette décision devrait être reconsidérée. OPTIONS est un nom de méthode HTTP valide et run_request n'est pas toujours une alternative appropriée. Si nous allons casser l'API publique, il vaut mieux le faire maintenant, avant de publier la 1.0, que de regretter la décision plus tard.

Pourquoi run_request n'est-il pas toujours une alternative appropriée ?

Pour les auteurs de bibliothèque de niveau inférieur qui s'appuient sur Faraday, je voudrais
recommande en fait d'utiliser run_request sur les méthodes get , post .

@mislav #run_request ne prend pas de bloc, comme #get , #post , etc. Jetez un œil à la façon dont j'utilise Faraday dans Twitter::REST::Client#request : https://github.com/sferik/twitter/blob/master/lib/twitter/rest/client.rb#L130 -L144

run_request ne prend pas de bloc, comme #get, #post, etc.

Qu'est-ce qui te fait penser ça ?

Votre cas d'utilisation est un parfait exemple d'utilisation de run_request , c'est-à-dire pour éviter send .

Maintenant, je me souviens pourquoi je n'aime pas #run_request . Je l'utilisais en fait à un moment donné dans le code Twitter::Client#request mais je l'ai supprimé dans le cadre d'une refactorisation : https://github.com/sferik/twitter/commit/2d70b64674bdc204c85c47327afa571f9641e545. Je pense que vous devez admettre que le code est beaucoup plus propre avec #send (je souhaite que ce ne soit pas le cas).

Avec #run_request , je devais me demander si la requête était un PUT ou POST et définir le corps de la requête par rapport aux paramètres de requête pour GET , DELETE , etc. Avec les méthodes verbales, je peux simplement leur passer un hachage et ils savent comment le gérer correctement. À mon humble avis, c'est une interface beaucoup plus conviviale qu'avec #run_request .

Je vous mets au défi de soumettre une pull request à la gem twitter qui remplace #send par #run_request qui donne un code moins complexe (selon Code Climate ou une autre analyse statique ).

En défense de la méthode OPTIONS , il est très difficile de deviner la popularité future des verbes HTTP. Dans HTTP 1.0, il n'y avait que GET et POST. En 1999, d'autres verbes ont été ajoutés dans HTTP 1.1, mais ils ont été pour la plupart ignorés jusqu'à ce que Rails 2 ajoute la prise en charge de PUT et DELETE dans les routes de ressources. Désormais, dans Rails 4, PATCH est pris en charge avec PUT . Il y a quelques années, vous avez peut-être (à juste titre) affirmé que « PATCH n'est pas très populaire » et ne nécessite donc pas un support de première classe. Aujourd'hui, tous les nouveaux serveurs d'API écrits en Rails prennent en charge PATCH , y compris l' API GitHub , qui prenait en charge PATCH avant la sortie de Rails 4. L'API GitHub prend également en charge OPTIONS pour le partage de ressources d'origine croisée (CORS). Cette utilisation de OPTIONS n'est peut-être pas encore populaire, mais elle le deviendra presque du jour au lendemain si CORS est ajouté par défaut dans Rails 5. Si cela se produit, je pense que vous regretterez d'avoir écarté ce problème.

Les verbes HTTP sont des mots réservés importants pour une bibliothèque HTTP. Il n'y en a que quelques-uns et à mon avis, nous devrions tous les soutenir en tant que citoyens de première classe dans Faraday 1.0, même si cela signifie casser les choses en cours de route.

CORS est un cas d'utilisation très important. Je serais déçu si 1.0 était livré sans OPTIONS en tant que verbe de première classe.

Je suis vraiment désolé de _bump_ cela, mais un accord sur la prise en charge de options comme méthode pour les demandes OPTIONS ? Je serais plus qu'heureux de soumettre une demande de tirage pour que cela se produise.

Je ne suis toujours pas convaincu par l'idée. Comment s'appellerait alors la méthode options ?

Les autres méthodes que nous prenons en charge sont les verbes : get, post, put, delete. Cela permet de comprendre facilement qu'une action se produit lorsque vous les appelez. options ne serait pas un verbe et en tant que tel, je ne pense pas que cela ferait une bonne méthode de raccourci. Si les gens utilisent OPTIONS une tonne de code au jour le jour et ne supportent pas d'utiliser run_request pour une raison quelconque (j'aimerais entendre cette raison !), alors je suggérerais en nommant la nouvelle méthode http_options pour indiquer qu'il s'agit d'une méthode de requête HTTP.

L'argument de « les autres méthodes sont des verbes » ne devrait pas avoir d'importance. Ce ne sont pas des méthodes en Faraday car ce sont des verbes, ces méthodes existent car ce sont des méthodes HTTP. La même chose devrait se produire pour options IMO.

Si c'est la raison pour laquelle options , alors head ne doit pas être défini, car "head" dans HTTP n'est pas "aller", le verbe.

J'ai tout à fait peur de casser l'API avec options , mais c'est une grande surprise qu'elle ne soit pas "supportée". Il est bien plus cohérent d'avoir toutes les méthodes HTTP gérées de la même manière.

Et à propos de ne pas utiliser run_request , comme cela a été indiqué auparavant, le code sans lui est beaucoup plus propre.

C'est toujours votre appel (évidemment :-) ) de décider de soutenir cela ou non, mais j'aimerais changer d'avis à ce sujet, et si cela ne va pas être soutenu, c'est pour autre chose que "_options_ n'est pas un verbe".

+1 @nhocki

Cela m'a pris par surprise aujourd'hui. Tous les exemples avec conn.get , conn.post , conn.delete etc. me portent à croire que le moyen évident de faire une requête OPTIONS était conn.options .

Peut-être pourrions-nous documenter cette incohérence et sa solution run_request contournement Faraday::Connection rdocs ou le README ? Je suis heureux de composer une demande de tirage.

+1

Pourquoi les options ne sont-elles pas les mêmes que GET, POST, DELETE ?

Même si je suis personnellement d'accord avec @mislav , je ne peux pas ignorer l'opinion de @sferik et les commentaires de la communauté. J'ai vérifié le code et j'ai remarqué que options est simplement un attr_reader , en plus il est principalement utilisé par les tests.
Cependant, nous parlons d'une API publique qui pourrait potentiellement casser certaines implémentations en cours de modification, par conséquent, cela ne sera traité que dans Faraday 1.0
D'ici là, heureux d'en rediscuter si quelqu'un est contre

Je pense que conn.options devrait totalement être une chose. Son existence est fortement liée à l'existence de conn.get , conn.post , etc. Mais comme cela briserait la rétrocompatibilité, la v1.0 semble être une bonne cible pour l'intégrer.

Bonnes nouvelles tout le monde! J'ai implémenté cela en surchargeant #options pour prendre en charge le nouveau comportement, tout en conservant le comportement existant. https://github.com/lostisland/faraday/pull/857