Httpie: Solicitud para agregar la opción `-d, --data` para cuerpo sin formato como curl

Creado en 31 oct. 2016  ·  18Comentarios  ·  Fuente: httpie/httpie

La solicitud es simple, solo para agregar una opción para pasar datos sin procesar como lo hace curl :

http :/api/user -d 'MyRawData...'

Sé que en la mayoría de los casos, si está enviando JSON o datos de formulario, se puede lograr con los _"elementos de solicitud"_, como:

http :/api/hey say=Hello to=me …

Y se convertirá al formato adecuado según el tipo de contenido, ¡eso es increíble! Y si tiene algo que no es un JSON o datos de formulario para enviar, puede hacer algo como:

echo 'MyRawData...' | http :/api/hey

Pero esto no es práctico, la idea principal de HTTPie es una _herramienta similar a cURL para humanos_, y este caso está lejos de ese principio, de hecho, curl es más práctico que HTTPie para el ejemplo anterior. Agregar más de un comando y canalizarlos con caracteres feos como | < solo porque falta una opción simple no suena _humano_ amigable_.

¿Qué hay de malo en agregar la opción -d a http ?

Comentario más útil

solo puedes hacer http POST example.org <<< "foo bar" o http POST example.org < file.name

Todos 18 comentarios

¿Qué tiene de malo agregar la opción -d a http?

No habría nada particularmente malo en eso. Solo encuentro limpiadores de tuberías y prefiero cuando solo hay una forma de hacer lo mismo. La tubería existe para este mismo propósito (es decir, para pasar _datos_ a los programas), y es fácil de entender, universal y sin ambigüedades. Todas las herramientas CLI decentes admiten tuberías (con la notable excepción de curl ), por lo que solo necesita aprender el concepto una vez.

Comparar:

httpie

Un método universal para pasar datos de solicitud es a través de stdin redirigido (entrada estándar). Dichos datos se almacenan en búfer y luego, sin más procesamiento, se utilizan como el cuerpo de la solicitud.

rizo

-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.

Sí, estoy de acuerdo contigo en que admitir tuberías en una herramienta de línea de comandos es una buena característica, y también creé una herramienta de línea de comandos que admite tuberías ( Mongotail ), y para ser honesto, no sabía que curl no lo soporta Pero creo que admitir ambas funciones no agrega complejidad, porque casi todas las herramientas CLI conocidas en el ecosistema de Unix admiten ambas formas. P.ej. cat , grep , find , tail ...

Los comandos que menciona generalmente aceptan una lista de argumentos de nombre de archivo o datos de entrada sin procesar a través stdin . Sin embargo, no aceptan los datos reales como argumentos. Aceptar datos sin procesar a través de un argumento es bastante poco común.

(Aclarando lo que escribí en un comentario anterior: curl admite stdin, pero debe recibir instrucciones explícitas para leerlo, por ejemplo, --data-binary @- ).

Vine aquí para presentar un error relacionado con este problema, por lo que tal vez no sea un error pero funcione según lo diseñado.

Tengo un script bash que estaba cambiando para usar "httpie" en lugar de "curl". Las solicitudes son POST de cuerpo vacío a un servidor http. Ejecuto este script conectándolo a un docker exec -i ${container} bash -x .

Me costó mucho darme cuenta de que el comando http POST , aunque funcionaba bien cuando se ejecutaba desde un shell interactivo, hacía que el script se cerrara inmediatamente.

Supongo que se trata de http leyendo stdin en docker exec . Parece extraño que tenga que canalizar " echo -n " para evitar esto.

#!/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 usted POST un cuerpo vacío simplemente con http POST httpbin.org/post . Lea acerca de los detalles del uso de HTTPie en el script : desea incluir la opción --ignore-stdin . Este es un problema no relacionado , sin embargo, así que abra un nuevo problema en lugar de responder aquí, si es necesario).

¿Tengo razón al pensar que 15.1 Solicitar datos de un nombre de archivo cubre la solicitud original de este problema? Supongo que este tema se puede cerrar.

Aparte, desearía haber sabido sobre HTTPie antes de ayer, ya que me habría evitado 3 horas más o menos para averiguar por qué no se conservaron los saltos de línea en mi archivo XML. (Pensé que era mi aplicación, pero era curl, que requiere que se use su opción --data-binary para dejar los datos en paz). ¡Gracias por HTTPie!

No es así, @DavidOliver . @mrsarm solicitó poder pasar una cadena desde el parámetro, no el contenido de un archivo.

+1

¿Aceptaría MR con esta característica @jakubroztocil ?

solo puedes hacer http POST example.org <<< "foo bar" o http POST example.org < file.name

http:/api/hey say=Hola a=yo...

solo puedes hacer http POST example.org <<< "foo bar" o http POST example.org < file.name

no parecía funcionar para powershell, 'raw body data' | http post :8080/api/events funcionó para mí en powershell,
pero todavía quiero -d, --data o algo así para transferir datos de un cuerpo sin procesar

de acuerdo con los documentos, puede usar una "cadena Bash here":

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

En cuanto a la interfaz de usuario, la opción tiene sentido.

Parece que no puedo encontrar una manera de enviar un objeto json vacío ( {} ), que es un caso de uso extraño pero válido.

@minusf : parece que no puedo encontrar una manera de enviar un objeto json vacío ( {} ), que es un caso de uso extraño pero válido.

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

¿Alguna forma de descartar la nueva línea mientras se redirige?

$ echo 20 | http POST httpbin.org/post

los datos archivados serían "data": "20\n"

@hahattan puede indicar a echo que no imprima el carácter de nueva línea final con -n :

$ echo -n foo | http httpbin.org/post
¿Fue útil esta página
0 / 5 - 0 calificaciones