Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: JSON support
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Cynthia Revström via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 21 Jan 2022 00:15:12 +0100
Hi,
I do quite frequently use curl with JSON for testing APIs and such and
thought I would give some input.
I think that there are certainly enough people who would like
something like this, but I do also see how it is quite different from
what is currently in curl.
1. As others have pointed out, jq is a widely used and excellent tool.
2. While normal multipart forms are (ime) typically just one "level"
of parameters, this is not at all always the case with JSON. (which
would increase the complexity I assume)
So I am not so certain if it is the right thing to be included in
curl, or at least not in the main binary or CLI interface or whatever
you want to call it.
However I do think that including some flag(s) to make it easier to
use premade JSON data (in a file or stdin or whatever).
This could be something like shortcuts for adding the "Content-Type:
application/json" and "Accept: application/json" headers.
Just looking at my shell history, commands including the following two
flags/parameters are quite common: "-H 'Content-Type:
application/json' --data _at_<jsonfile>"
Being able to just write something like "--json _at_<jsonfile>" would be
a lot more convenient.
P.S. I am new to this list, so I apologize if I misunderstood something.
-Cynthia
On Thu, Jan 20, 2022 at 10:51 PM Daniel Stenberg via curl-users
<curl-users_at_lists.haxx.se> wrote:
>
> On Thu, 20 Jan 2022, Pierre Brico via curl-users wrote:
>
> > That isn't the role of curl to worry about the content of the data sent.
>
> No? Here are a few existing options:
>
> curl -d name=foo -d size=9 ... (when more than one -d is used)
>
> curl -F name=foo -F file=_at_here.jpg ...
>
> curl --data-urlencode name=$USER ...
>
> I'm fairly sure all of these are used widely and they all do decisions and
> build buffers that are "target specific" content to send.
>
> It isn't an entirely new and foreign concept.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-users
> Etiquette: https://curl.haxx.se/mail/etiquette.html
Date: Fri, 21 Jan 2022 00:15:12 +0100
Hi,
I do quite frequently use curl with JSON for testing APIs and such and
thought I would give some input.
I think that there are certainly enough people who would like
something like this, but I do also see how it is quite different from
what is currently in curl.
1. As others have pointed out, jq is a widely used and excellent tool.
2. While normal multipart forms are (ime) typically just one "level"
of parameters, this is not at all always the case with JSON. (which
would increase the complexity I assume)
So I am not so certain if it is the right thing to be included in
curl, or at least not in the main binary or CLI interface or whatever
you want to call it.
However I do think that including some flag(s) to make it easier to
use premade JSON data (in a file or stdin or whatever).
This could be something like shortcuts for adding the "Content-Type:
application/json" and "Accept: application/json" headers.
Just looking at my shell history, commands including the following two
flags/parameters are quite common: "-H 'Content-Type:
application/json' --data _at_<jsonfile>"
Being able to just write something like "--json _at_<jsonfile>" would be
a lot more convenient.
P.S. I am new to this list, so I apologize if I misunderstood something.
-Cynthia
On Thu, Jan 20, 2022 at 10:51 PM Daniel Stenberg via curl-users
<curl-users_at_lists.haxx.se> wrote:
>
> On Thu, 20 Jan 2022, Pierre Brico via curl-users wrote:
>
> > That isn't the role of curl to worry about the content of the data sent.
>
> No? Here are a few existing options:
>
> curl -d name=foo -d size=9 ... (when more than one -d is used)
>
> curl -F name=foo -F file=_at_here.jpg ...
>
> curl --data-urlencode name=$USER ...
>
> I'm fairly sure all of these are used widely and they all do decisions and
> build buffers that are "target specific" content to send.
>
> It isn't an entirely new and foreign concept.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-users
> Etiquette: https://curl.haxx.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-21