Re: [atlas] Breaking API change?

2022-10-24 Thread Ray Bellis




On 24/10/2022 10:13, Chris Amin wrote:

Hi Ray,

This is indeed a breaking change, although the new behaviour is arguably 
more logical. The missing link here is the "use_keys" parameter, which 
was always supported but used to default to true when "fields" was 
present, and false otherwise. It now defaults to false unless explicitly 
specified.


You can get the previous behaviour with the following URL:

<${apiUrl}/measurements/${m}/latest/?fields=responses.0.response_time,responses.0.abuf.answers.0.data.0=1800_keys=true>

Does this work for you?


I'll give that a test later and let you know.  I did manage to work 
around the new structure on the live site.


BTW, I also found (by accident) that in order to get the probe ID I had 
to use field=probe_id, not prb_id.  Is that intended?


cheers,

Ray



--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas


Re: [atlas] Breaking API change?

2022-10-24 Thread Chris Amin

Hi Ray,

This is indeed a breaking change, although the new behaviour is arguably 
more logical. The missing link here is the "use_keys" parameter, which 
was always supported but used to default to true when "fields" was 
present, and false otherwise. It now defaults to false unless explicitly 
specified.


You can get the previous behaviour with the following URL:

<${apiUrl}/measurements/${m}/latest/?fields=responses.0.response_time,responses.0.abuf.answers.0.data.0=1800_keys=true>

Does this work for you?

Kind regards,
Chris Amin
RIPE NCC

On 22/10/2022 15:37, Ray Bellis wrote:


ISC's Root System Atlas visualiser used to use this API call to access 
the built-in root system measurements:


<${apiUrl}/measurements/${m}/latest/?fields=responses.0.response_time,responses.0.abuf.answers.0.data.0=1800>

where ${m} is the measurement number.

It used to return this object:

{
   probe_id1: [ [ latency, site1 ], ... ]
   probe_id2: [ [ latency, site1 ], ... ]
   ...
}

It now returns this array instead:

[
   [probe_id1, latency, site],
   ...
   [probe_id1, latency, site],

   [probe_id2, latency, site],
   ...

]

and I had to explicitly request the probe_id field in order to get it.

Was this change intentional, a regression, or did I not use the API 
right in the first place?


cheers,

Ray





--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas