Jeff Albrecht

This is a good way to encapsulate all of the logic required to generate base URL for links including forwarding headers, router prefixes etc.

Adding an optional caching layer at the edge of the API makes sense to me. Either as a middleware or a decorator (fastapi-cache). I think its generally preferable in production...

I think moving the backends into their own repos is a great idea, I see many benefits: - Enforce better separation of concerns between API layer and backend implementations. -...

Ideally these tests are done against the API layer instead of individual backends.

It's possible but it could be difficult. POST requests use the `stac_pydantic.api.Search` model (https://github.com/stac-utils/stac-pydantic/blob/master/stac_pydantic/api/search.py#L36). In order to do this we'd have to define a stricter type for `Search.query` than what...

> though where does it stop? This. it's a very slippery slope. What would be helpful in the spec is to provide a way for servers which implement the query...

> Right, and without knowing too much backstory myself, it looks like the query extension is deprecated so it seems questionable how much effort is justified. Deprecated in favor of...

Thats interesting. My interpretation of the spec was that the search endpoint should only accept geojson geometry types, not any of the geometry containers. Here is the language in the...

wow I'm awful at reading 😆 > The semantics are intersection with any of the geometries in the geometry collection. 👍

Currently we aren't using the stac-pydantic search model (https://github.com/stac-utils/stac-fastapi/blob/master/stac_fastapi/types/stac_fastapi/types/search.py#L85-L86). But it looks like we could be using it from the docstring.