Faraday: Löscht mit Körper

Eine PR wird in Kürze für Ihre Überprüfung bereitgestellt.

Hallo @Carlbc18 ,

Könnten Sie bitte einen Link zu den oben genannten Änderungen bereitstellen?
Ich denke, das gilt nur für HTTP 2.0-Spezifikationen, daher müssen wir diese Funktion möglicherweise sorgfältig prüfen.

https://tools.ietf.org/html/rfc7231#section -4.3.5

Zu Ihrer Information: Der gleiche Textblock gilt auch für GET && HEAD-Anfragen.

speziell dieser Teil der Spezifikation:

Eine Nutzlast innerhalb einer DELETE-Anforderungsnachricht hat keine definierte Semantik;
Das Senden eines Nutzlast-Bodys bei einer DELETE-Anforderung kann dazu führen, dass einige vorhandene
Implementierungen, um die Anfrage abzulehnen.

Ich habe eine Codeänderung mit Tests, die funktioniert (nicht sicher, ob Sie es wollen). Wie erstelle ich eine PR für dieses Projekt?

Ich denke, das gilt nur für HTTP 2.0-Spezifikationen, daher müssen wir diese Funktion möglicherweise sorgfältig prüfen.

dies ist eigentlich Teil von HTTP 1.1

Ich würde es auf jeden Fall in Betracht ziehen, wenn Sie eine PR erstellen möchten.
Sie können es wie bei jedem anderen Repository tun, einfach faraday forken und die Änderungen auf Ihren Fork anwenden und dann einen PR für unseren Master-Zweig erstellen.

Danke @iMacTia. Ich werde es aufstellen. Was halten Sie von der Änderung der Version, die damit endlich eine Hauptversionsnummer hat? Diese Veränderung könnte für viele schädlich sein. Ich möchte dem Semver-Muster folgen und die Faraday-Version zu diesem Zeitpunkt 1.0.0 sein. Lass mich wissen was du denkst.

Wir versuchen auf jeden Fall, beim Semver zu bleiben und haben v1.0 mit einigen bahnbrechenden Änderungen geplant.
Wenn diese Änderung die Abwärtskompatibilität beeinträchtigt, wird sie nur in Version 1.0 veröffentlicht (die derzeit kein festes Veröffentlichungsdatum hat).
Ich verstehe jedoch, dass Sie jetzt OPTIONAL einen Text zu GET-, HEAD- und DELETE-Anforderungen hinzufügen können. Sollte das also nicht abwärtskompatibel sein? Verpasse ich etwas?

@iMacTia Ich habe auf 0.13.0 versioniert und der PR ist hoch. Wir können jede andere Konversation zu diesem Thema in die PR mitnehmen, da ich sicher bin, dass es Kommentare geben wird. Danke noch einmal!

Dies ist ein Follow-up zu meinem https://github.com/lostisland/faraday/pull/695#issuecomment -305145499.
Zunächst sollten wir uns entscheiden, WIE wir dies haben möchten.
Unter der Annahme, dass die Änderungen abwärtskompatibel sein sollten, sollte Folgendes weiterhin funktionieren:

conn = Faraday.new(...)
conn.get('/path', {page: 1, per: 10})

# performs "GET /path?page=1&per=10"

Option 1, wie in meinem Kommentar angegeben, wäre, dieses Verhalten konfigurierbar zu machen:

conn = Faraday.new(..., standard: :http1_1)
conn.get('/path', {page: 1, per: 10})

# performs "GET /path" with body "page=1&per=10" (assuming www_form_url_encoded request)

Option 2 würde stattdessen etwas Mächtigeres bedeuten:

conn = Faraday.new(...) # note no special config here
conn.get('/path', {page: 1, per: 10}, body: {some_key: 'some_value')

# performs "GET /path?page=1&per=10" with body "some_key=some_value"

Es gibt jedoch ein Problem, Option 2 funktioniert möglicherweise nur mit Ruby >= 2, da Ruby 1.9 keine Schlüsselwortparameter unterstützt 😞

Ich denke, in Bezug darauf, dass es bei Ruby 1.9 nicht funktioniert, finde ich das in Ordnung. Ruby 1.9 ist viele Jahre alt. Ich würde dafür plädieren, dass wir die Version auf mindestens 2.0 für die minimale Ruby-Version erhöhen, die mit einer v1.0-Version von Faraday in Einklang stehen würde. Auch Option 2 folgt meiner Meinung nach der http 1.1-Spezifikation, da Sie die Möglichkeit haben, Parameter und/oder einen optionalen Körper zu übergeben.

Ich habe das Gefühl, dass der Versuch, die Abwärtskompatibilität mit einer http-Spezifikationsfunktion aufrechtzuerhalten, die mit Ruby 1.9 funktioniert, Probleme verursachen wird. Ich denke, diese Funktion wäre besser für V1 von Faraday geeignet. Ich habe das Gefühl, dass zu viele Variablen diese Änderung unterstützen mussten (Ruby v, Parameterübergabe). Vielleicht überlege ich zu viel....

Ich denke, in Bezug darauf, dass es bei Ruby 1.9 nicht funktioniert, finde ich das in Ordnung. Ruby 1.9 ist viele Jahre alt. Ich würde dafür plädieren, dass wir die Version auf mindestens 2.0 für die minimale Ruby-Version erhöhen, die mit einer v1.0-Version von Faraday in Einklang stehen würde. Auch Option 2 folgt meiner Meinung nach der http 1.1-Spezifikation, da Sie die Möglichkeit haben, Parameter und/oder einen optionalen Körper zu übergeben.

Ich stimme allen oben genannten voll und ganz zu. Das ist in der Tat die beste Vorgehensweise, auch wenn das bedeutet, dass wir noch auf v1.0 warten müssen

Um eine abwärtskompatible API v1.0 zu definieren, könnten wir Folgendes versuchen:

ANFRAGEN ERHALTEN, KOPFERN, LÖSCHEN

conn = Faraday.new(...) # note no special config here
conn.get(path, url_params, body: {...})
# second parameter is URL PARAMS, optionally accept a named parameter for request body
# works the same for head and delete

POST-, PUT-, PATCH-ANFRAGEN

conn = Faraday.new(...) # note no special config here
conn.post(path, body, url_params: {...})
# second parameter is REQUEST BODY, optionally accept a named parameter for url_params
# works the same for put and patch

Ich denke, auf diese Weise decken wir jede mögliche Kombination ab und erweitern auch Post/Put/Patch-Anfragen!

Stimme auf jeden Fall zu. Wollen wir meine PR ablehnen und dafür eine neue eröffnen? Gibt es einen V1-Zweigschnitt, an dem wir arbeiten können?

Ich freue mich, dieses zu schließen und von vorne anzufangen, da es völlig anders sein wird. Das tut mir leid!

Ich werde einen V1-Zweig erstellen, bevor ich mich einfüge, also beginne gerne mit dem Master und ich werde die PR umleiten :)

Hallo @Carlbc18 wollte mitteilen , dass die Filiale 1.0 jetzt für dich verfügbar ist 😃.

Danke Danke! 😀

Für alle, die noch darauf warten, habe ich die folgende Problemumgehung gefunden, die in meinem Fall zu funktionieren scheint:

conn = Faraday.new
body = {
some_key: 'some value'
}
conn.run_request(:delete, url, body, headers)

Ich hoffe, das hilft jemandem, bis das Löschen den Körper standardmäßig nicht mehr aufhebt.

Gibt es also ein Update, wann das verfügbar sein wird?

Ich habe noch keine PR gesehen, aber die Arbeiten an v1 schreiten langsam voran.
Ich kann vielleicht selbst daran arbeiten, kann aber im Moment keine Schätzung abgeben.
Die aktualisierte API zur Funktionsweise von Anfragen wird in meinem obigen Kommentar erläutert. Wenn also jemand vor mir eine Chance darauf haben möchte, ist eine PR sehr willkommen.

Für eine vollständig abwärtskompatible Lösung kann der PR vom Master abgezweigt werden, und ich kann eine weitere 0.x-Version erstellen.
Wenn die Änderung die Abwärtskompatibilität beeinträchtigt, ist es besser, aus dem 1.0 Zweig zu verzweigen

https://github.com/lostisland/faraday/pull/855 ist ein PR-Entwurf, um dies zu unterstützen.

Ich lehne diese Funktion ab. Sie können das Sperrformular in Faraday verwenden, um eine Anfrage mit einem Text zu stellen:

conn.delete(url) do |req|
  req.body = { some_key: 'some value' }
end

Diese Idee hätte einfache Löschungen mit Körpern zu einem einzigen Einzeiler gemacht, aber die Implementierung fügt mehr Komplexität und überraschendes Verhalten hinzu, als mir lieb ist. Diese Blockform funktioniert in Faraday bereits hervorragend. Ich ziehe es vor, Eigenschaften einer Klasse zu ändern, anstatt einer Methode weitere Argumente hinzuzufügen:

conn.delete('/foo/1') do |req|
  req.headers["X-Men"] = "marvel"
  req.params[:confirm] = 1
  req.body = { some_key: 'some value' }
end