Add community extension: Collection Search Endpoint

[jonhealy1]

Adds a new community extension to support a dedicated Collection Search Endpoint.

Repository: https://github.com/Healy-Hyperspatial/stac-api-extensions-collection-search-endpoint

Motivation

This extension defines a dedicated /collections-search endpoint to resolve a routing conflict in the STAC API ecosystem.

Currently, the standard Collection Search extension relies on POST /collections for advanced filtering. However, this path collides with the Transaction Extension, which uses POST /collections for creating new collections.

While Content-Type negotiation is the theoretical solution, it creates significant implementation friction in frameworks like stac-fastapi. This extension formalizes the "Sidecar Pattern" (using /collections-search) to allow both Transactions and Advanced Search to coexist robustly on the same API.

Implementation:
We are currently implementing this specification in the stac-fastapi-elasticsearch-opensearch project.

[m-mohr]

I have a couple of concerns regarding this extension:

1. The name is confusing. There would be "Collection Search" and "Collection Search Endpoint", which is probably confusing to users.
2. I'm not sure why a new endpoint is needed. GET /collections probably covers most of the usecases. POST /collections indeed conflicts with transaction, but we could aim to add QUERY /collections to the existing extension (see Add support for QUERY /collections collection-search#23). We could add that today, I think. (I'm aware that support for QUERY could still be lacking in some places as it's close to standardization, but not fully through the procedure yet.)
3. (I'm also generally wondering, why people want POST /collections but never asked for this for /collections/{collectionId}/items, where the same conflict exists. I think in the long run it's better to use QUERY as a HTTP method as POST is semantically incorrect anyway as we don't created resources. See also QUERY /search and QUERY /collections/{collectionId}/items radiantearth/stac-api-spec#465)

Having that said, the decision to merge is up to the PSC.

[jonhealy1]

@m-mohr

1. I am open to changing the name. I think it's pretty clear, but I did come up with it.

2. Using QUERY is an interesting idea, but is it fully supported in AWS etc.?

3. People use /search generally for Item search. Item collection /items GET search requests are an extra added feature. For this reason, it makes sense to have a /collections-search endpoint.

With Items:

1. GET search requests on /items
2. GET and POST on /search

Collections:

1. GET search requests on /collections
2. GET and POST on /collections-search

Would we remove /search if we can now do QUERY on the /items endpoint as well?

[m-mohr]

Using QUERY is an interesting idea, but is it fully supported in AWS etc.?

I don't use AWS, I don't know. Once standardized, which I think happens in 2026, it will likely be implemented widely at latest.

People use /search generally for Item search. Item collection /items GET search requests are an extra added feature. For this reason, it makes sense to have a /collections-search endpoint.

That doesn't describe what I'm seeing people do. I see usage across both endpoints for Item Search. I don't follow your conclusion.

By the way, can someone provide me with a Collection Search query that a user tried and didnt work through GET?

Would we remove /search if we can now do QUERY on the /items endpoint as well?

/items (more precisely /collections/{id}/items) is items per collection, /search is item search across collections. As such we can't remove it any of them even if QUERY /search would be available.

---

I think long-term it should be for a consistent interface:

Items:

• GET and QUERY on /collections/{id}/items
• GET and QUERY on /search (POST deprecated)

Collections:

• GET and QUERY on /collections

[jonhealy1]

• Well you can search on one collection with /search too.

I think you have to remember that this pr is aiming to add this to a list as a community-hosted stac api extension and not trying push this into core use.

Because this extension is hosted externally, the stac-api-extensions repository is not responsible for actively encouraging people to use it.

I would be happy to deprecate this externally-hosted stac api extension when the QUERY http method is standardized.