I was looking at converting some of my code built on API v1 to v2, and I noticed an odd thing in how GET /places/{uuid} works vs GET /observations/{uuid}.
Specifically, GET /places/{uuid} will accept either numeric ID values or UUIDs in the uuid parameter. For example, these all return the same 2 places:
- (numeric IDs) https://api.inaturalist.org/v2/places/1,18?fields=all
- (UUIDs) https://api.inaturalist.org/v2/places/981d9cf2-e161-4c66-af02-493dc335be47,1899cd1b-04a8-4513-b416-22a394dc6b04?fields=all
- (mixed) https://api.inaturalist.org/v2/places/1,1899cd1b-04a8-4513-b416-22a394dc6b04?fields=all
- (mixed, in v1) https://api.inaturalist.org/v1/places/1,1899cd1b-04a8-4513-b416-22a394dc6b04
… but GET /observations/{uuid} really does accept only UUIDs. For example, these return different results:
- (numeric ID) https://api.inaturalist.org/v2/observations/352915138?fields=all
- (UUID) https://api.inaturalist.org/v2/observations/32e8620f-dd26-411a-b3df-87bc95bbbeaf?fields=all
I noticed this because I was trying to figure out how to get place information when GET /observations and GET /observations/{uuid} return only a place_ids array (and not a place_uuids array or something similar that provides place UUIDs). given this, it’s useful that GET /v2/places/{uuids} accepts the numeric IDs, but it seems unintuitive and inconsistent, given the way the other endpoint works.
So then, what was the rationale for making one endpoint work one way and the other work another way? Are there future plans to change the way either works to make them more consistent?
(Personally, I think it would be nice to return at least a little more place information in the GET /observations and GET /observations{uuid} response. instead of just place id, providing admin level, and name could reduce or completely eliminate the need to do additional requests to GET /places to display, say, the standard places associated with each observation.)