Leider verfügt Connection bereits über den Accessor options sodass wir ihn nicht für eine OPTIONS-Anfrage verwenden können. Sie müssen run_request(:options)

Vielleicht ist es eine naive Annahme, aber wäre es nicht einfacher, :options zuzuordnen, ich weiß nicht, :configuration , anstatt ein anderes Nutzungsmuster zu haben?

Ich möchte eine etablierte API nicht ändern, um ein selten verwendetes HTTP zu unterstützen
-Methode, die über run_request leicht zugänglich ist.

IMHO sollte diese Entscheidung noch einmal überdacht werden. OPTIONS ist ein gültiger HTTP-Methodenname und run_request ist nicht immer eine geeignete Alternative. Wenn wir die öffentliche API zerstören, ist es besser, dies jetzt zu tun, bevor wir 1.0 veröffentlichen, als die Entscheidung später zu bereuen.

Warum ist run_request nicht immer eine geeignete Alternative?

Für untergeordnete Bibliotheksautoren, die auf Faraday aufbauen, würde ich
empfehlen die Verwendung von run_request über get , post Methoden.

@mislav #run_request braucht keinen Block, wie #get , #post usw. Sehen Sie sich an, wie ich Faraday in Twitter::REST::Client#request : https://github.com/sferik/twitter/blob/master/lib/twitter/rest/client.rb#L130 -L144

run_request nimmt keinen Block an, wie #get, #post usw.

Was lässt Sie so denken ?

Ihr Anwendungsfall ist ein perfektes Beispiel für die Verwendung von run_request , dh um send zu vermeiden.

Jetzt erinnere ich mich, warum ich #run_request nicht mag. Ich habe es tatsächlich einmal im Twitter::Client#request Code verwendet, es aber im Rahmen eines Refactorings entfernt: https://github.com/sferik/twitter/commit/2d70b64674bdc204c85c47327afa571f9641e545. Ich denke, Sie müssen zugeben, dass der Code mit #send viel sauberer ist (ich wünschte, dies wäre nicht der Fall).

Bei #run_request musste ich mir Gedanken machen, ob die Anfrage ein PUT oder POST und den Anfragetext vs. die Anfrageparameter auf GET , DELETE , etc. Mit den Verbmethoden kann ich ihnen einfach einen Hash übergeben und sie wissen, wie man damit richtig umgeht. IMHO, dies ist eine viel freundlichere Benutzeroberfläche als bei #run_request .

Ich fordere Sie auf, eine Pull-Anfrage an das Juwel twitter zu senden, das #send durch #run_request , was zu weniger komplexem Code führt (gemäß Code Climate oder einer anderen statischen Analyse). ).

Zur Verteidigung der Methode OPTIONS ist es sehr schwer, die zukünftige Popularität von HTTP-Verben abzuschätzen. In HTTP 1.0 gab es nur GET und POST. 1999 wurden in HTTP 1.1 weitere Verben hinzugefügt, die jedoch größtenteils ignoriert wurden, bis Rails 2 Unterstützung für PUT und DELETE in Ressourcenrouten hinzufügte. In Rails 4 wird jetzt PATCH neben PUT . Vor einigen Jahren haben Sie vielleicht (zu Recht) behauptet, dass „ PATCH nicht sehr beliebt ist“ und daher keinen erstklassigen Support benötigt. Heute unterstützen alle neuen API-Server, die in Rails geschrieben wurden, PATCH , einschließlich der GitHub-API , die PATCH bevor Rails 4 veröffentlicht wurde. Die GitHub-API unterstützt auch OPTIONS für Cross Origin Resource Sharing (CORS). Diese Verwendung von OPTIONS vielleicht noch nicht populär, aber sie wird fast über Nacht populär, wenn CORS als Standard in Rails 5 hinzugefügt wird.

HTTP-Verben sind wichtige reservierte Wörter für eine HTTP-Bibliothek. Es gibt nur wenige von ihnen und meiner Meinung nach sollten wir sie alle als erstklassige Bürger in Faraday 1.0 unterstützen, auch wenn das bedeutet, dass auf dem Weg dorthin etwas kaputt geht.

CORS ist ein sehr wichtiger Anwendungsfall. Ich wäre enttäuscht, wenn 1.0 ohne OPTIONS als erstklassiges Verb ausgeliefert würde.

Es tut mir furchtbar leid, dass ich das _stoße_, aber irgendeine Vereinbarung über die Unterstützung von options als Methode für OPTIONS Anfragen? Ich würde gerne eine Pull-Anfrage senden, um dies zu ermöglichen.

Ich bin immer noch nicht von der Idee überzeugt. Wie würde dann die aktuelle Methode options heißen?

Andere Methoden, die wir unterstützen, sind Verben: get, post, put, delete. Es macht es leicht zu verstehen, dass eine Aktion stattfindet, wenn Sie sie anrufen. options wäre kein Verb und als solches denke ich nicht, dass es eine schöne Kurzschriftmethode wäre. Wenn Leute OPTIONS eine Tonne im täglichen Code verwenden und es aus irgendeinem Grund nicht ertragen können, run_request zu verwenden (ich würde diesen Grund gerne hören!), dann würde ich vorschlagen Benennen Sie die neue Methode http_options um anzuzeigen, dass dies eine HTTP-Anforderungsmethode ist.

Das Argument "die anderen Methoden sind Verben" sollte keine Rolle spielen. Sie sind keine Methoden in Faraday, weil sie Verben sind, diese Methoden existieren, weil sie HTTP-Methoden sind. Das gleiche sollte für options IMO passieren.

Wenn dies der Grund dafür ist, dass options , dann sollte head nicht definiert werden, da es bei "head" in HTTP nicht um "going" geht, das Verb.

Ich habe total Bedenken, die API mit options brechen, aber es ist eine große Überraschung, dass sie nicht "unterstützt" wird. Es ist viel konsistenter, wenn alle HTTP-Methoden gleich behandelt werden.

Und darüber, dass run_request , wie bereits erwähnt, der Code ohne ist viel sauberer.

Es ist immer noch Ihre Entscheidung (offensichtlich :-) ) zu entscheiden, ob Sie dies unterstützen möchten oder nicht, aber ich würde Ihre Meinung gerne ändern, und wenn es nicht unterstützt wird, ist es für etwas anderes als "_options_ is not" ein Verb".

+1 @nhocki

Das hat mich heute überrascht. Alle Beispiele mit conn.get , conn.post , conn.delete usw. lassen mich glauben, dass der offensichtliche Weg, eine OPTIONS-Anfrage auszuführen, conn.options .

Vielleicht könnten wir diese Inkonsistenz und ihren run_request Workaround in den Faraday::Connection rdocs oder der README dokumentieren? Gerne verfasse ich eine Pull-Anfrage.

+1

Warum sind Optionen nicht gleich GET, POST, DELETE?

Auch wenn ich persönlich @mislav zustimme, kann ich die Meinung von @sferik und das Feedback der Community nicht ignorieren. Ich habe den Code überprüft und festgestellt, dass options einfach ein attr_reader ist und außerdem hauptsächlich von Tests verwendet wird.
Wir sprechen jedoch von einer öffentlichen API, die möglicherweise einige geänderte Implementierungen beschädigen könnte. Daher wird dies nur in Faraday 1.0 behandelt
Bis dahin gerne noch einmal darüber diskutieren, falls jemand dagegen ist

Ich denke, conn.options sollte eine Sache sein. Seine Existenz hängt stark von der Existenz von conn.get , conn.post usw. ab. Aber da es die Abwärtskompatibilität zerstören würde, klingt v1.0 wie ein nettes Ziel, um dies zu integrieren.

Gute Nachrichten, Leute! Ich habe dies implementiert, indem ich #options überladen habe, um das neue Verhalten zu unterstützen, während das vorhandene Verhalten beibehalten wird. https://github.com/lostisland/faraday/pull/857