The Met's collection API tells you when a search finds nothing, but not with an empty list

What it covers

The Collection API serves the Met's public domain and open access objects: titles, artists, dates, departments, and image URLs. No key and no sign-up are needed.

GET /departments, queried live this session, returned 200 with a list of 19 departments, from American Decorative Arts to Asian Art. GET /objects returned 200 with a total of 502,689 object IDs.

GET /objects/45734, queried live, returned a full record for a 17th-century painting by Kiyohara Yukinobu. The record includes the artist name, the object date, the department, and two image URLs. It marks the object as public domain.

A search with no results is not an empty list

GET /search?q=sunflowers, tried live this session, returned 200 with a total of 97 and a list of matching object IDs.

GET /search?q=zzzzqqqqxxxx, a query built to match nothing, also returned 200. But the body reads {"total":0,"objectIDs":null}. The objectIDs field is not an empty array. It is null.

A caller who reads objectIDs.length off that response crashes. The fix is a null check before the length check, not after.

A missing object and a bad path fail differently

GET /objects/999999999, a numeric ID that does not exist, returned 404 with {"message":"ObjectID not found"}.

GET /nonsense, a path the API does not define at all, also returned 404, but with a different body: {"message":"Not Found"}.

Both are honest 404s. Neither collapses into a generic error page. A caller can tell a bad ID from a bad route by reading the message field alone.

This session also sent an Origin header on a request to /departments and got back Access-Control-Allow-Origin: *, confirming the catalogue's cors: yes entry for this API.