curl / Mailing Lists / curl-users / Single Mail
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

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

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-users
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2022-01-20