I've not used the API but I'm familiar with other Google services and am a Photos user.
If you consider you're experience with photos.google.com, you browse a somewhat unstructured list of all your photos. The Photos (phone|browser) apps do categorize photos by date but you have to search to filter by other metadata to find the specific photo(s) that you're seeking. Or you happy-scroll through years of photos of your cat.
This contrasts with another common metaphor for arranging files in which a hierarchy of folders is used to categorize the content e.g. /photos/cats/2022
but this mechanism is limited because you can only really navigate through one dimension (the folders).
Considerable metadata (type, width|height, creation date etc.) is associated with each photo and it is customary in schemas like this to construct a unique ID for each object. The unique ID is sometimes exposed to the end-user but not necessarily. Identifiers are generally for the system's own purposes.
With Photos, there are public, unique identifiers in the form of URLs for each photos but evidently the id
and the URL although probably related (perhaps via a hash) aren't obviously related.
So, since it's not always possible to specific a photo uniquely by e.g. "The one of my dog where he's wearing sunglasses because of the eclipse" and the absence of folders, a really powerful alternative (which you'll need to employ) is to search for some subset of the photos and then iterate over the results.
It appears that the Photos service has such a search
to which you provide Filters
and each of the items in the results will be a MediaItem (uniquely identified by id
).
Unlike the file system example above, because Photos does not use a fixed hierarchy, we can view our Photos by filtering them using an extensive set of metadata: photos of cats, taken in 2022, using my phone.