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&freshness=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
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&freshness=1800&use_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&freshness=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
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&freshness=1800&use_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
Hi Ray, On 24/10/2022 14:05, Ray Bellis wrote:
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 Yes, the field names actually use the ripe-atlas-sagan parser conventions rather than the standard measurement result keys, so "probe_id" rather than "prb_id".
One note: the "fields=" parameter is not actually a publicly documented feature of the API, which is the main reason why it was changed in a backwards-incompatible way. However we have no immediate plans to drop support for it, and I'll let you know if we're considering it. "use_keys" is also not currently documented, but we will upgrade that to be fully documented/supported in the near future. Cheers, Chris
participants (2)
-
Chris Amin -
Ray Bellis