Re: JSON support

From: Timothe Litt <litt_at_acm.org>
Date: Fri, 21 Jan 2022 05:48:45 -0500

On 21-Jan-22 03:42, Pierre Brico wrote:

> 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.
Here's a rough outline of how to do that.

Since we expect that the output will be JSON, cURL could wrap the output
in an object - and perhaps add some metadata:

{

   "http_code" :  "200";
   "http_success" : true;
   "http_content-type" :  "application/json";
   "initial_url" : "http://www.example.org/service/json";
   "final_url" : "https://example.org/service/json";
   "certificate_status" : "expired";
   "response_data" :
     (whatever came back, typically an object - if it's not JSON, just
make it a string);
}

You can use jq in a function or script to extract the data if you're
going into a legacy tool, or account for the nesting in a new one.  You
can use tee in a pipeline to check the status inline while saving the
data for a separate command.

jq (input) | curl | tee result.json | jq (get status)  && jq
(response)<result.json

There should be a default set of metadata.  One can add to it with the
%{...} syntax, for example if one wants timing or expensive/rarely-used
elements.  Exactly what the default should be requires some thought; the
items above are just a starting point.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 21-Jan-22 03:42, Pierre Brico wrote:
>
> 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.html

Received on 2022-01-21