APIs.json 0.24 changes one thing: where an APIs.json document lives. It defines /.well-known/apis.json as a well-known URI under RFC 8615, so the path can be registered with IANA. No new properties, no schema change beyond the version label.
Twelve years of "it is intended"
Since the earliest drafts, section 3.7 has said that "if there is sufficient traction, the 'well known' location '/apis.json' ... will be submitted" — under RFC 5785, which RFC 8615 has since obsoleted. The traction came. Providers publish APIs.json at /.well-known/apis.json today; ten of the twelve sites in the showcase serve a valid document there. What never happened was the submission, and the IANA registry requires that the specification itself define the value as a well-known URI before it can be registered. 0.24 does that.
What changed
- Section 3.1, Access method.
/.well-known/apis.jsonis now the location a publisher SHOULD use and a robot SHOULD request first. The root/apis.*paths remain conformant, so nothing that works today stops working. - Section 3.7, Well Known. A normative definition of the
apis.jsonwell-known URI — it returns an APIs.json document describing the APIs operated on or offered by that origin — and the IANA registration template. - RFC 9727. The
api-catalogwell-known URI already lists APIs.json as one of the catalog formats it can point to. 0.24 makes the relationship explicit: the two are complementary, a publisher may serve both, anapi-cataloglinkset may link to/.well-known/apis.json, and a robot that finds one should follow it to the other.
Read the 0.24 specification or the schema. Why now is in The Well-Known Folder Is Filling Up.