Rework update_openapi function.

[eseglem]

Related Issue(s):

• I was thinking Declare non-200 responses in OpenAPI docs #363 might be an good place to start contributing but that ended up leading me to here while I was familiarizing myself with the code.

Description:
The current implementation of update_openapi duplicates code from fastapi/applications.py#L216 without context and could end up out of sync with the source. Rather than duplicating code this implementation just wraps it and modifies the response's content-type header.

While there are tests for the content-type header in other portions of the repo, there was not one in stac_fastapi/api/tests. To ease debugging I added a test to have one closer to the code that implements it.

I also removed the code that was marked with a TODO to remove or fix it. It was not being utilized and it seems like stac_fastapi/api/app.py#L311 would be the place to do any changes in the future. While I did just notice #499 would remove that function for now, I still believe that would be the appropriate location if modifications to the schema are necessary in the future.

PR Checklist:

• Code is formatted and linted (run pre-commit run --all-files)
• Tests pass (run make test)
• Documentation has been updated to reflect changes, if applicable, and docs build successfully (run make docs)
• Changes are added to the CHANGELOG.

[gadomski]

Looks good -- I left one inline comment requesting more documentation so I can feel better about my knowledge of how the patching is working.

I requested changes b/c I think it would be more appropriate to deprecate, rather than than remove, the unused functions and classes. While we don't have a published deprecation strategy for stac-fastapi (note to self: TODO), there's enough implementations of this repo in the wild that I'm cautious about any breaking changes, however small. IMO deprecating both VndOaiRespone and config_openapi, with a plan to remove in v3.0, would be appropriate.

Thanks for the contribution!

[eseglem]

@gadomski Added the functions back and added some deprecation warnings to them. It seems unlikely to be necessary, but being cautious is reasonable.

It doesn't prevent private repos from using them, but there are no repos outside of stac-utils that have any mention of VndOaiResponse. And the only other use of config_openapi is an earlier fork: https://github.com/c-core-labs/stac-api which contains the function itself. The config_openapi also calls a function which no longer exists, and it probably cannot be used without an error.

I also made some minor tweaks to the patch to hopefully make it more clear. There are potentially other options, like a hybrid of the old implementation of this one. Still create a new route, but with this patched endpoint function. I am certainly biased, but I prefer this way because it requires the least changes and code so there are less things to go wrong.

[geospatial-jeff]

LGTM