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: Timothe Litt <litt_at_acm.org>
Date: Thu, 20 Jan 2022 09:47:17 -0500
+1. No, +10.
Note that jq is a multiplatform, highly portable tool - it should run
pretty much anywhere cURL does.
https://stedolan.github.io/jq/download/
Referencing jq as companion tool in cURL's documention would be a way to
help users without adding out of scope complexity to cURL.
For cases where JSON is desired as a library, every platform and
language has multiple JSON encoding and decoding libraries.
I don't think it's necessary to reference them - anyone using libcurl
should be able to find them with minimal effort.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 20-Jan-22 09:37, Pierre Brico via curl-users wrote:
> Hi Daniel,
>
> I totally agree with Jeffrey. That isn't the role of curl to
> worry about the content of the data sent.
>
> Personally, I very often use curl to write testing scripts. Those
> scripts need to deal with JSON to consume REST API. To manipulate the
> JSON format, I use the awesome tool jq.
>
> Here is 2 very frequent use-cases:
>
> 1/ Building JSON message:
>
> map="transactionAmount=1.00
> transactionCurrencyCode=EUR
> transactionTrackingCode=$transactionTrackingCode
> transactionCallbackUrl=https://website.com/callback
> transactionLanguageCode=fr
> transactionCountryCode=BE
> customerEmail=john.doe_at_email.com"
>
> message=$(echo "$map" | *jq -Rn '[ inputs
> | gsub("\r$"; "")
> | split("="; "")
> | select(length == 2)
> | {(.[0]): .[1]}
> ] | add'*)
>
> [ $VERBOSE == "Y" ] && echo "$message" | *jq -C "."*
>
> httpCode=$(curl $CURL_OPT -w "%{http_code}" -H "Content-Type:
> application/json" "https://$AWS_HOST/$AWS_ENV$API_PAYMENTS" --data
> "$message" -o $OUTPUT)
>
> 2/ Parsing JSON result
>
> transactionId=$(*jq -r '.transactionId' $OUTPUT*)
> echo "Payment transactionId is $transactionId"
>
> The problem with dealing with JSON format is that it can become tricky
> when manipulating complex structures with arrays. jq tool does an
> excellent job in this domain.
>
>
> Pierre
>
>
>
> On Thu, Jan 20, 2022 at 3:15 PM Jeffrey Walton via curl-users
> <curl-users_at_lists.haxx.se> wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 8:39 AM Daniel Stenberg via curl-users
> <curl-users_at_lists.haxx.se> wrote:
> >
> > I've been circling around this topic before. On this list I've
> previously
> > gotten rather lukewarm responses or even several "don't do its",
> but after
> > having asked around people on twitter I think maybe the time
> might come when
> > we add some JSON specific command line options to the tool.
> >
> > I have three reasons why now:
> >
> > 1. Sending JSON has grown to become a very common thing to do in
> the world of
> > REST APIs and more.
> >
> > 2. When asked what features or functionality people like in the
> many curl
> > "alteratives" that pop up, the "ease of doing JSON" is a
> frequent answer.
> >
> > 3. A not insignificant amount of people on stackoverflow etc
> have problems to
> > send correct JSON with curl and to get the quoting done right,
> as json uses
> > double-qoutes by itself and shells don't expand variables within
> single quotes
> > etc.
> >
> > I personally am not sending JSON too often myself so I'm pretty
> sure I'm not
> > suitable to design this feature entirely on my own. I need help
> to design this
> > to become as useful as possible.
> >
> > I've drafted my refreshed concept in the curl wiki. To explain
> it shortly, it
> > adds two command line options: one for sending already formatted
> json as a
> > shortcut for -d with the right Accept header, and the other is
> an option for
> > building a json request body to send. See the expanded thoughts
> here:
> >
> > https://github.com/curl/curl/wiki/JSON
> >
> > That page was previously describing a slightly different json
> idea, so if you
> > looked at it before, look again because it's different now.
> >
> > Is this a good idea? What tweaks does it need to become useful?
> If you're
> > sending JSON with curl or an alternative tool today, could you
> see yourself
> > using this method instead and what would be needed for that to
> be really
> > attractive for you?
>
> JSON is presentation layer. I don't think it is core to cURL.
> However... when users have trouble it is often a good idea to help
> them along.
>
> I would consider a design that layers the JSON support on top of cURL.
> Maybe something like a 'curlson' utility. Curlson could do the JSON
> communication using the underlying curl library. Curlson could also
> provide a way to just set a value using positional argument, similar
> to a parameterized query, and without a lot of the shell escaping.
>
> Jeff
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-users
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>
>
Received on 2022-01-20
Date: Thu, 20 Jan 2022 09:47:17 -0500
+1. No, +10.
Note that jq is a multiplatform, highly portable tool - it should run
pretty much anywhere cURL does.
https://stedolan.github.io/jq/download/
Referencing jq as companion tool in cURL's documention would be a way to
help users without adding out of scope complexity to cURL.
For cases where JSON is desired as a library, every platform and
language has multiple JSON encoding and decoding libraries.
I don't think it's necessary to reference them - anyone using libcurl
should be able to find them with minimal effort.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 20-Jan-22 09:37, Pierre Brico via curl-users wrote:
> Hi Daniel,
>
> I totally agree with Jeffrey. That isn't the role of curl to
> worry about the content of the data sent.
>
> Personally, I very often use curl to write testing scripts. Those
> scripts need to deal with JSON to consume REST API. To manipulate the
> JSON format, I use the awesome tool jq.
>
> Here is 2 very frequent use-cases:
>
> 1/ Building JSON message:
>
> map="transactionAmount=1.00
> transactionCurrencyCode=EUR
> transactionTrackingCode=$transactionTrackingCode
> transactionCallbackUrl=https://website.com/callback
> transactionLanguageCode=fr
> transactionCountryCode=BE
> customerEmail=john.doe_at_email.com"
>
> message=$(echo "$map" | *jq -Rn '[ inputs
> | gsub("\r$"; "")
> | split("="; "")
> | select(length == 2)
> | {(.[0]): .[1]}
> ] | add'*)
>
> [ $VERBOSE == "Y" ] && echo "$message" | *jq -C "."*
>
> httpCode=$(curl $CURL_OPT -w "%{http_code}" -H "Content-Type:
> application/json" "https://$AWS_HOST/$AWS_ENV$API_PAYMENTS" --data
> "$message" -o $OUTPUT)
>
> 2/ Parsing JSON result
>
> transactionId=$(*jq -r '.transactionId' $OUTPUT*)
> echo "Payment transactionId is $transactionId"
>
> The problem with dealing with JSON format is that it can become tricky
> when manipulating complex structures with arrays. jq tool does an
> excellent job in this domain.
>
>
> Pierre
>
>
>
> On Thu, Jan 20, 2022 at 3:15 PM Jeffrey Walton via curl-users
> <curl-users_at_lists.haxx.se> wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 8:39 AM Daniel Stenberg via curl-users
> <curl-users_at_lists.haxx.se> wrote:
> >
> > I've been circling around this topic before. On this list I've
> previously
> > gotten rather lukewarm responses or even several "don't do its",
> but after
> > having asked around people on twitter I think maybe the time
> might come when
> > we add some JSON specific command line options to the tool.
> >
> > I have three reasons why now:
> >
> > 1. Sending JSON has grown to become a very common thing to do in
> the world of
> > REST APIs and more.
> >
> > 2. When asked what features or functionality people like in the
> many curl
> > "alteratives" that pop up, the "ease of doing JSON" is a
> frequent answer.
> >
> > 3. A not insignificant amount of people on stackoverflow etc
> have problems to
> > send correct JSON with curl and to get the quoting done right,
> as json uses
> > double-qoutes by itself and shells don't expand variables within
> single quotes
> > etc.
> >
> > I personally am not sending JSON too often myself so I'm pretty
> sure I'm not
> > suitable to design this feature entirely on my own. I need help
> to design this
> > to become as useful as possible.
> >
> > I've drafted my refreshed concept in the curl wiki. To explain
> it shortly, it
> > adds two command line options: one for sending already formatted
> json as a
> > shortcut for -d with the right Accept header, and the other is
> an option for
> > building a json request body to send. See the expanded thoughts
> here:
> >
> > https://github.com/curl/curl/wiki/JSON
> >
> > That page was previously describing a slightly different json
> idea, so if you
> > looked at it before, look again because it's different now.
> >
> > Is this a good idea? What tweaks does it need to become useful?
> If you're
> > sending JSON with curl or an alternative tool today, could you
> see yourself
> > using this method instead and what would be needed for that to
> be really
> > attractive for you?
>
> JSON is presentation layer. I don't think it is core to cURL.
> However... when users have trouble it is often a good idea to help
> them along.
>
> I would consider a design that layers the JSON support on top of cURL.
> Maybe something like a 'curlson' utility. Curlson could do the JSON
> communication using the underlying curl library. Curlson could also
> provide a way to just set a value using positional argument, similar
> to a parameterized query, and without a lot of the shell escaping.
>
> Jeff
> --
> 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.html
- application/pgp-signature attachment: OpenPGP digital signature