Is there a document somewhere that talks about the extent to which the current api’s will be compatible with the new data structure (if there is going to be a new data structure to support the new apis).
How long (if at all) will the old api interface be supported once the new api’s are live?
if you’re talking about v2 vs v1, i haven’t done a deep dive comparison of the two, but just in my limited experience with both of them, it seems to me like the underlying data models are more or less the same, and changes to the model in v2 are also reflected in v1. as far as i’ve seen, the main things that are different are:
although you have to make the requests differently because you have to explicitly specify fields in v2, i haven’t seen any cases where – as long as you’ve specified all the necessary fields in your v2 request, and as long as you’re referring to the objects in your response by key – that you generally have to change any code that handles a v1 response vs a v2 response, unless maybe you have subsequent requests that you need to make based on UUIDs in v2 instead of numeric IDs in v1.
if you’re talking about the deprecated API, then that has been deprecated for a long time, and it doesn’t seem to be getting updated, and yet it’s still up and running. i don’t see any signs that it’s going to ever go away, but we’ll see…
I have used the v2 API off and on for a few years, and haven’t seen any changes beyond bug fixes. I have never had a reason to track UUIDs; I suspect that actually requiring them would be too great a (coordination, programming) challenge. Same for changing the meaning of any existing field. I take the difficulty of change as a stronger guarantee that it won’t happen than a promise not to change anything.
GBIF’s API might be better documented, and of course provides data from multiple datasets. Downsides include a lag for changes and new observations, no casual observations, no private coordinates, no access to the iNaturalist taxonomy (though this can be downloaded as a darwincore archive).
That’s very helpful. I didn’t know there was an old version that had already been deprecated. I just wondered if there was a document somewhere that said how much warning consumers of the v1’s would get if and when they were going to drop support. I’m not too worried about it, just wondered if it was spelled out somewhere.
This was always the hardest part of working on back-ends. If there were data structure changes you felt trapped supporting the old versions of api’s because the consumers took so long to code to the new interface. And it was really complicated when the structure changed. In our case, the consumers were paying us, so we had to wait forever and support the old interface when we were ready to move on.
compare:
also:
i’m fairly certain the shift to uuids is meant to provide greater information privacy. it’s not a complete shift, and the protection is not perfect, but it’s probably a step in the right direction.
Yes, that was the intention. There is no benefit to privacy until the API and site no longer vend sequential IDs, which will not happen.
i guess we’ll see. the implementation of v2 certainly provides them the option to make the switch at least. you would have to fully turn off v1 and (most of) the deprecated API before you can actually flip the switch though.