How to handle CQL2 Item Filters for APIs that don't implement Features Filter conformance class

[alukach]

Context

#17 added functionality that applied a CQL2 filter to any requests made to /collections/{collection_id}/items. However, reviewing the Conformance Classes section of the Filter Extension¹, we see:

The implementation may support the OAFeat Part 3 Features Filter conformance classes:

• Features Filter (http://www.opengis.net/spec/ogcapi-features-3/1.0/conf/features-filter) binds the Filter and CQL2 conformance classes to the Features resource (/collections/{cid}/items).

While the Filter extension is a hard requirement of the Item Filtering functionality of STAC Auth Proxy, we should support upstream APIs that don't implement Features Filter.

Ideas

A configuration variable could dictate whether to pass through requests to upstream APIs that support the Features Filter. However, the proxy's behavior when the Features Filter is not supported is yet to be determined.

Transparently serve /search content

The proxy could proxy content from the Item search endpoint.

Example:

• incoming request:
• generated CQL2: "naip:year"='2022'
• request sent to upstream STAC API: /search?filter="naip:year"='2022'

This works as the response bodies are almost identical, except for the links attribute:

▶ curl -s "http://localhost:8001/search?filter=collection='naip'" | jq .links            
[
  {
    "rel": "root",
    "type": "application/json",
    "href": "http://localhost:8001/"
  },
  {
    "rel": "self",
    "type": "application/json",
    "href": "http://localhost:8001/search?filter=collection='naip'"
  }
]
▶ curl -s "http://localhost:8001/collections/naip/items" | jq .links           
[
  {
    "rel": "collection",
    "type": "application/json",
    "href": "http://localhost:8001/collections/naip"
  },
  {
    "rel": "parent",
    "type": "application/json",
    "href": "http://localhost:8001/collections/naip"
  },
  {
    "rel": "root",
    "type": "application/json",
    "href": "http://localhost:8001/"
  },
  {
    "rel": "self",
    "type": "application/geo+json",
    "href": "http://localhost:8001/collections/naip/items"
  }
]

The proxy could attempt to rewrite these on the outgoing response (the rel property would make it simple to assess what needs to be swapped) but this could get sticky (e.g. consider pagination).

Explicitely redirect to /search

Perhaps it would be better to return a simple redirect to the client, informing them that the content is available via the Item Search endpoint.

A purist could say this would knock the API out of compliance with the STAC specification. However, the effective behavior would be roughly the same.

Footnotes

1. https://github.com/stac-api-extensions/filter?tab=readme-ov-file#conformance-classes ↩