This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Breaking API change?
- Previous message (by thread): [atlas] Breaking API change?
- Next message (by thread): [atlas] Breaking API change?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ray Bellis
ray at isc.org
Mon Oct 24 14:05:54 CEST 2022
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
- Previous message (by thread): [atlas] Breaking API change?
- Next message (by thread): [atlas] Breaking API change?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]