Httpie: Anfrage zum Hinzufügen der Option "-d, --data" für Rohkörper wie Curl

Was ist falsch daran, die Option -d zu http hinzuzufügen?

Daran wäre nichts _besonders_ falsch. Ich finde Rohrleitungen einfach sauberer und bevorzuge es stark, wenn es nur eine Möglichkeit gibt, dasselbe zu tun. Piping existiert genau für diesen Zweck (dh um _Daten_ an Programme zu übergeben), und es ist einfach zu verstehen, universell und eindeutig. Jedes anständige CLI-Tool unterstützt Piping (mit der bemerkenswerten Ausnahme von curl ), sodass Sie das Konzept nur einmal lernen müssen.

Vergleichen:

httpie

Eine universelle Methode zum Übergeben von Anforderungsdaten ist die umgeleitete Standardeingabe (Standardeingabe). Diese Daten werden zwischengespeichert und dann ohne weitere Verarbeitung als Anfragetext verwendet.

kräuseln

-d, --data <data>
              (HTTP)  Sends  the  specified data in a POST request to the HTTP server, in the same way that a browser
              does when a user has filled in an HTML form and presses the submit button. This will cause curl to pass
              the  data  to  the  server  using  the  content-type application/x-www-form-urlencoded.  Compare to -F,
              --form.

              -d, --data is the same as --data-ascii. --data-raw is almost the same  but  does  not  have  a  special
              interpretation of the @ character. To post data purely binary, you should instead use the --data-binary
              option.  To URL-encode the value of a form field you may use --data-urlencode.

              If any of these options is used more than once on the same command line, the data pieces specified will
              be merged together with a separating &-symbol. Thus, using '-d name=daniel -d skill=lousy' would gener-
              ate a post chunk that looks like 'name=daniel&skill=lousy'.

              If you start the data with the letter @, the rest should be a file name to read the data from, or -  if
              you  want  curl  to read the data from stdin. Multiple files can also be specified. Posting data from a
              file named 'foobar' would thus be done with --data @foobar. When --data is told to  read  from  a  file
              like  that,  carriage  returns  and newlines will be stripped out. If you don't want the @ character to
              have a special interpretation use --data-raw instead.

Ja, ich stimme Ihnen zu, dass die Unterstützung von Piping in einem Befehlszeilentool eine gute Funktion ist, und ich habe auch ein Befehlszeilentool erstellt, das Piping unterstützt ( Mongotail ), und um ehrlich zu sein, wusste ich das nicht curl unterstützt es nicht. Aber ich denke, dass die Unterstützung beider Funktionen die Komplexität nicht erhöht, da fast alle bekannten CLI-Tools im Unix-Ökosystem beide Möglichkeiten unterstützen. Z.B. cat , grep , find , tail ...

Die von Ihnen erwähnten Befehle akzeptieren im Allgemeinen entweder eine Dateinamen-Argumentliste oder rohe Eingabedaten über stdin . Sie akzeptieren jedoch nicht die tatsächlichen Daten als Argumente. Das Akzeptieren von Rohdaten über ein Argument ist ziemlich ungewöhnlich.

(Zur Klarstellung, was ich in einem früheren Kommentar geschrieben habe: curl unterstützt stdin, aber es muss ausdrücklich angewiesen werden, es mit beispielsweise --data-binary @- zu lesen.)

Kam hierher, um einen Fehler im Zusammenhang mit diesem Problem zu melden, also ist es vielleicht kein Fehler, sondern funktioniert wie vorgesehen.

Ich habe ein Bash-Skript, das ich geändert habe, um "httpie" anstelle von "curl" zu verwenden. Die Anforderungen sind POSTs mit leerem Textkörper an einen HTTP-Server. Ich führe dieses Skript aus, indem ich es in eine docker exec -i ${container} bash -x .

Es fiel mir schwer herauszufinden, dass der http POST -Befehl, obwohl er gut funktionierte, wenn er von einer interaktiven Shell aus ausgeführt wurde, dazu führte, dass das Skript sofort beendet wurde.

Ich schätze, es geht um http das Lesen von stdin in docker exec . Es scheint seltsam, dass ich " echo -n " pfeifen muss, um dies zu vermeiden.

#!/bin/bash
echo "STARTING..."
echo -n | http POST ...     # this replaces: curl -XPOST --data-binary '' ...
echo "Without the 'echo -n' above this statement would not be reached."
echo "DONE"

( @jamshid Sie POST einen leeren Körper einfach mit http POST httpbin.org/post . Bitte lesen Sie die Besonderheiten der Verwendung von HTTPie in Skripten – Sie möchten die Option --ignore-stdin einschließen. Dies ist kein verwandtes Problem , öffnen Sie also bei Bedarf bitte ein neues Problem, anstatt hier zu antworten.)

Gehe ich richtig in der Annahme, dass 15.1 Daten von einem Dateinamen anfordern die ursprüngliche Anfrage dieser Ausgabe abdeckt? Ich denke, dieses Thema kann geschlossen werden.

Abgesehen davon wünschte ich, ich hätte HTTPie vor gestern gewusst, da ich etwa 3 Stunden vermieden hätte, um herauszufinden, warum Zeilenumbrüche in meiner XML-Datei nicht beibehalten wurden. (Ich dachte, es wäre meine App, aber es war curl, was erfordert, dass die Option --data-binary verwendet wird, um die Daten in Ruhe zu lassen.) Danke für HTTPie!

Das tut es nicht, @DavidOliver . @mrsarm forderte an, eine Zeichenfolge vom Parameter übergeben zu können, nicht den Inhalt einer Datei.

+1

Würden Sie MR mit dieser Funktion @jakubroztocil akzeptieren ?

Sie können einfach http POST example.org <<< "foo bar" oder http POST example.org < file.name tun

http :/api/hey say=Hallo zu=mich …

Sie können einfach http POST example.org <<< "foo bar" oder http POST example.org < file.name tun

schien nicht für Powershell zu funktionieren, 'raw body data' | http post :8080/api/events funktionierte für mich auf Powershell,
aber ich will trotzdem -d, --data oder so ähnlich, um rohe Körperdaten zu übertragen

Laut den Dokumenten können Sie eine "Bash here string" verwenden:

http example.com/ <<<'{"name": "John"}'

In Bezug auf die Benutzeroberfläche ist die Option sinnvoll.

Ich kann anscheinend keinen Weg finden, ein leeres JSON-Objekt ( {} ) zu senden, was ein seltsamer, aber gültiger Anwendungsfall ist.

@minusf : Ich kann anscheinend keinen Weg finden, ein leeres JSON-Objekt ( {} ) zu senden, was ein seltsamer, aber gültiger Anwendungsfall ist.

$ echo '{}' | http httpbin.org/post

Gibt es eine Möglichkeit, den Zeilenumbruch beim Umleiten zu verwerfen?

$ echo 20 | http POST httpbin.org/post

die abgelegten Daten wären "data": "20\n"

@hahattan Sie können echo anweisen, das abschließende Zeilenumbruchzeichen mit -n nicht zu drucken:

$ echo -n foo | http httpbin.org/post