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: Pierre Brico via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 21 Jan 2022 09:42:41 +0100
Just my 2 cents: when consuming a REST API using JSON, the HTTP status code
is very important as it informs clients of their request’s overarching
result (see https://restfulapi.net/http-status-codes/).
That's the reason why I always execute API calls into 2 phases:
1) httpCode=$(curl -w "%{http_code}" -o OUTPUT.json ...) to get the status
code (and do the necessary processing).
2) value=$(jq -r '.object1.object2.propertyName' OUTPUT.json) to extract
value(s) from the API response.
I don't think this could be actually possible using just one command line
with a pipe. If anyone sees how to improve this, it could be nice.
Pierre
On Fri, Jan 21, 2022 at 1:33 AM Timothe Litt via curl-users <
curl-users_at_lists.haxx.se> wrote:
> Agree with the analysis.
>
> --json file which sets the headers and provides input seems like a good
> approach - it makes things simpler for the user without adding a lot of
> complexity to curl.
>
> I suspect that the most common usage will be jq (or another generator)
> piped into curl feeding a consumer tool, so syntax that optimizes that case
> should be considered. e.g. jq ... | curl --json uri | consumer
>
> 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 18:15, Cynthia Revström via curl-users wrote:
>
> 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
>
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-users
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>
Date: Fri, 21 Jan 2022 09:42:41 +0100
Just my 2 cents: when consuming a REST API using JSON, the HTTP status code
is very important as it informs clients of their request’s overarching
result (see https://restfulapi.net/http-status-codes/).
That's the reason why I always execute API calls into 2 phases:
1) httpCode=$(curl -w "%{http_code}" -o OUTPUT.json ...) to get the status
code (and do the necessary processing).
2) value=$(jq -r '.object1.object2.propertyName' OUTPUT.json) to extract
value(s) from the API response.
I don't think this could be actually possible using just one command line
with a pipe. If anyone sees how to improve this, it could be nice.
Pierre
On Fri, Jan 21, 2022 at 1:33 AM Timothe Litt via curl-users <
curl-users_at_lists.haxx.se> wrote:
> Agree with the analysis.
>
> --json file which sets the headers and provides input seems like a good
> approach - it makes things simpler for the user without adding a lot of
> complexity to curl.
>
> I suspect that the most common usage will be jq (or another generator)
> piped into curl feeding a consumer tool, so syntax that optimizes that case
> should be considered. e.g. jq ... | curl --json uri | consumer
>
> 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 18:15, Cynthia Revström via curl-users wrote:
>
> 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
>
> --
> 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