A solicitação é simples, apenas para adicionar uma opção para passar dados brutos como curl
faz:
http :/api/user -d 'MyRawData...'
Eu sei que na maioria dos casos, se você estiver enviando JSON ou dados de formulário, isso pode ser alcançado com os _"request items"_, como:
http :/api/hey say=Hello to=me …
E ele será convertido para o formato adequado, dependendo do tipo de conteúdo, isso é incrível! E se você tiver algo que não seja um JSON ou dados de formulário para enviar, você pode fazer algo como:
echo 'MyRawData...' | http :/api/hey
Mas isso é impraticável, a ideia principal do HTTPie é _ferramenta tipo cURL para humanos_ , e esse caso está longe desse princípio, de fato, curl
é mais prático que HTTPie para o exemplo anterior. Adicionar mais de um comando e canalizá-los com caracteres feios como |
<
só porque uma opção simples está faltando não soa _amigável para humanos_.
O que há de errado em adicionar a opção -d
a http
?
O que há de errado em adicionar a opção -d ao http?
Não haveria nada _particularmente_ errado com isso. Eu apenas acho a tubulação mais limpa e prefiro quando há apenas uma maneira de fazer a mesma coisa. A tubulação existe para esse propósito (ou seja, para passar _dados_ para programas), e é fácil de entender, universal e não ambíguo. Toda ferramenta CLI decente suporta tubulação (com a notável exceção de curl
), então você só precisa aprender o conceito uma vez.
Comparar:
Um método universal para passar dados de solicitação é por meio de stdin redirecionado (entrada padrão). Esses dados são armazenados em buffer e, em seguida, sem processamento adicional usado como corpo da solicitação.
-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.
Sim, concordo com você que suportar tubulação em uma ferramenta de linha de comando é um bom recurso, e também fiz uma ferramenta de linha de comando que suporta tubulação ( Mongotail ), e para ser honesto eu não sabia que curl
não suporta. Mas acho que o suporte a ambos os recursos não adiciona complexidade, porque quase todas as ferramentas CLI conhecidas no ecossistema Unix suportam as duas maneiras. Por exemplo. cat
, grep
, find
, tail
...
Os comandos que você menciona geralmente aceitam uma lista de argumentos de nome de arquivo ou dados de entrada brutos por meio de stdin
. No entanto, eles não aceitam os dados reais como argumentos. Aceitar dados brutos por meio de um argumento é bastante incomum.
(Esclarecendo o que escrevi em um comentário anterior: curl
suporta stdin, mas precisa ser explicitamente instruído a lê-lo com, por exemplo, --data-binary @-
.)
Vim aqui para registrar um bug relacionado a esse problema, então talvez não seja um bug, mas funcione como projetado.
Eu tenho um script bash que estava mudando para usar "httpie" em vez de "curl". As solicitações são POSTs de corpo vazio para um servidor http. Eu corro esse script canalizando-o para um docker exec -i ${container} bash -x
.
Tive dificuldade em descobrir que o comando http POST
, embora funcionasse bem quando executado a partir de um shell interativo, estava fazendo com que o script saísse imediatamente.
Eu acho que é algo sobre http
lendo stdin no docker exec
. Parece estranho que eu tenha que canalizar " echo -n
" para evitar isso.
#!/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 você POST
um corpo vazio simplesmente com http POST httpbin.org/post
. Leia sobre as especificidades do uso de HTTPie no script — você deseja incluir a opção --ignore-stdin
. Este é um problema não relacionado , no entanto, abra um novo problema em vez de responder aqui, se necessário.)
Estou certo em pensar que 15.1 Solicitar dados de um nome de arquivo cobre a solicitação original deste problema? Acho que esse assunto pode ser encerrado.
Como um aparte, eu gostaria de saber sobre HTTPie antes de ontem, pois teria evitado 3 horas ou mais para descobrir por que as quebras de linha no meu arquivo XML não estavam sendo preservadas. (Achei que era meu aplicativo, mas era curl, o que requer que sua opção --data-binary
seja usada para deixar os dados em paz.) Obrigado por HTTPie!
Não, @DavidOliver . @mrsarm solicitou poder passar uma string do parâmetro, não o conteúdo de um arquivo.
+1
Você aceitaria MR com este recurso @jakubroztocil ?
você pode apenas fazer http POST example.org <<< "foo bar"
ou http POST example.org < file.name
http :/api/hey say=Olá para=me…
você pode apenas fazer
http POST example.org <<< "foo bar"
ouhttp POST example.org < file.name
parecia não funcionar para o powershell, 'raw body data' | http post :8080/api/events
funcionou para mim no powershell,
mas ainda quero -d, --data
ou algo assim para transferir dados brutos do corpo
de acordo com os documentos, você pode usar um "Bash here string":
http example.com/ <<<'{"name": "John"}'
Em termos de interface do usuário, a opção faz sentido.
não consigo encontrar uma maneira de enviar um objeto json vazio ( {}
), que é um caso de uso estranho, mas válido.
@minusf : não consigo encontrar uma maneira de enviar um objeto json vazio (
{}
), que é um caso de uso estranho, mas válido.
$ echo '{}' | http httpbin.org/post
alguma maneira de descartar a nova linha durante o redirecionamento?
$ echo 20 | http POST httpbin.org/post
os dados arquivados seriam "data": "20\n"
@hahattan você pode instruir echo
para não imprimir o caractere de nova linha final com -n
:
$ echo -n foo | http httpbin.org/post
Comentários muito úteis
você pode apenas fazer
http POST example.org <<< "foo bar"
ouhttp POST example.org < file.name