OGC API - Records supports a number of deployment patterns for catalogs.

The crawlable catalog pattern involves creating static metadata files along with the data, in a web accessible location (e.g.: S3 bucket). At top-level, there should be a file to provide information about the catalog, including links to navigate through the metadata records.

Although providing only visibility and navigation, the crawlable catalog comes with a very low implementation burden, and it can be low hanging fruit in terms of organising directories full of files (e.g.: EO images).

The searchable catalog pattern also allows accessing collection level metadata and the individual metadata records but, unlike the crawlable catalog, it enables clients to filter the response with query parameters. This searching capability requires the metadata to be stored in a SQL or NoSQL database that can provide the querying functionality, so the simple setup using files on a web accessible folder is no longer possible.

These are some real-life examples of querying patterns that can be used in a searchable catalog.

The /collections endpoint exists in many other OGC APIs (e.g.: features, coverages).

The local resources catalog pattern extends other OGC APIs endpoints to behave like catalogs, enabling querying functionality. For instance, this query filters a feature collection by bounding box:

curl -X 'GET' \
'https://emotional.byteroad.net/collections/hex350_grid_obesity_1920/items?bbox=-0.078921,51.473444,-0.063901,51.478062' \
-H 'accept: application/geo+json'

Other OGC API endpoints that can be repurposed as catalogs, include processes and coverage scenes.

You can read more about the OGC API - Records Standard on the editor's draft and follow/participate (in) its development on the Standard's GitHub repository .