Httpie: Запрос на добавление опции `-d, --data` для необработанного тела, такого как curl

Созданный на 31 окт. 2016  ·  18Комментарии  ·  Источник: httpie/httpie

Запрос прост, просто добавьте возможность передавать необработанные данные, как это делает curl :

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

Я знаю, что в большинстве случаев, если вы отправляете JSON или данные формы, это можно сделать с помощью _"элементов запроса"_, например:

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

И он будет преобразован в правильный формат в зависимости от типа контента, и это здорово! И если у вас есть что-то, что не является JSON или данными формы для отправки, вы можете сделать что-то вроде:

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

Но это непрактично, основная идея HTTPie — это _cURL-подобный инструмент для людей_, и этот случай далек от этого принципа, на самом деле curl более практичен, чем HTTPie для предыдущего примера. Добавление более одной команды и передача их уродливыми символами, такими как | < только потому, что отсутствует простая опция, не звучит _дружественно к человеку_.

Что не так с добавлением опции -d к http ?

Самый полезный комментарий

вы можете просто сделать http POST example.org <<< "foo bar" или http POST example.org < file.name

Все 18 Комментарий

Что не так с добавлением опции -d к http?

В этом не было бы ничего _особенно_ плохого. Я просто нахожу средство для чистки труб и очень предпочитаю, когда есть только один способ сделать то же самое. Конвейер существует именно для этой цели (т.е. для передачи _данных_ программам), и он прост для понимания, универсален и недвусмыслен. Каждый приличный инструмент CLI поддерживает конвейерную обработку (за исключением curl ), поэтому вам нужно изучить эту концепцию только один раз.

Сравнивать:

httpпи

Универсальный метод передачи данных запроса — через перенаправленный стандартный ввод (стандартный ввод). Такие данные буферизуются и затем без дальнейшей обработки используются в качестве тела запроса.

завиток

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

Да, я согласен с вами, что поддержка конвейерной обработки в инструменте командной строки — это хорошая функция, а также я сделал инструмент командной строки, поддерживающий конвейерную обработку ( Mongotail ), и, честно говоря, я не знал, что curl не поддерживает это. Но я думаю, что поддержка обеих функций не добавляет сложности, потому что почти все известные инструменты CLI в экосистеме Unix поддерживают оба способа. Например. cat , grep , find , tail ...

Упомянутые вами команды обычно принимают либо список аргументов имени файла, либо необработанные входные данные через stdin . Однако они не принимают фактические данные в качестве аргументов. Принятие необработанных данных через аргумент встречается довольно редко.

(Уточнение того, что я написал в предыдущем комментарии: curl действительно поддерживает стандартный ввод, но для его чтения необходимо явно указать, например, --data-binary @- .)

Пришел сюда, чтобы сообщить об ошибке, связанной с этой проблемой, так что, возможно, это не ошибка, а работа, как задумано.

У меня есть сценарий bash, который я изменил, чтобы использовать «httpie» вместо «curl». Запросы представляют собой POST-сообщения с пустым телом на http-сервер. Я запускаю этот скрипт, перенаправляя его в docker exec -i ${container} bash -x .

Мне было трудно понять, что команда http POST , хотя и работала нормально при запуске из интерактивной оболочки, приводила к немедленному завершению сценария.

Я предполагаю, что это что-то о http чтении stdin в docker exec . Кажется странным, что я должен передать " echo -n ", чтобы избежать этого.

#!/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 you POST пустое тело просто с http POST httpbin.org/post . Пожалуйста, прочитайте об особенностях использования HTTPie в скрипте — вы хотите включить опцию --ignore-stdin . Это не связанная проблема , однако, поэтому, если необходимо, откройте новый вопрос , а не отвечайте здесь.)

Прав ли я, думая, что 15.1 Запросить данные из имени файла охватывает первоначальный запрос этой проблемы? Думаю, этот вопрос можно закрыть.

Кроме того, мне жаль, что я не знал о HTTPie до вчерашнего дня, поскольку я бы избегал 3 часов или около того, выясняя, почему разрывы строк в моем файле XML не сохранялись. (Я думал, что это мое приложение, но оказалось, что это curl, для которого требуется использовать параметр --data-binary , чтобы оставить данные в покое.) Спасибо за HTTPie!

Это не так, @DavidOliver . @mrsarm запросил возможность передачи строки из параметра, а не содержимого файла.

+1

Примете ли вы MR с этой функцией @jakubroztocil ?

вы можете просто сделать http POST example.org <<< "foo bar" или http POST example.org < file.name

http :/api/hey say=Привет=мне …

вы можете просто сделать http POST example.org <<< "foo bar" или http POST example.org < file.name

казалось, что это не работает для powershell, 'raw body data' | http post :8080/api/events работало для меня на powershell,
но все еще хочу -d, --data или что-то в этом роде, чтобы передать необработанные данные тела

в соответствии с документами вы можете использовать «строку Bash здесь»:

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

С точки зрения пользовательского интерфейса этот вариант имеет смысл.

я не могу найти способ отправить пустой объект json ( {} ), что является странным, но допустимым вариантом использования.

@minusf : я не могу найти способ отправить пустой объект json ( {} ), что является странным, но допустимым вариантом использования.

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

любой способ отказаться от новой строки при перенаправлении?

$ echo 20 | http POST httpbin.org/post

поданные данные будут "data": "20\n"

@hahattan вы можете указать echo не печатать завершающий символ новой строки с помощью -n :

$ echo -n foo | http httpbin.org/post
Была ли эта страница полезной?
0 / 5 - 0 рейтинги