chore: validate stac api response with openapi_schema_validator

[stephenkilbourn]

Issue

#332

What?

Currently, we test the api endpoints to ensure the correct response code (e.g. 200). This expands the tests to use the open api validator to validate the response body against the stac open api spec. Currently, the docs are showing the response for these two endpoints as just any string, e.g.:

I've used a subset of the open api spec at https://api.stacspec.org/ to manually document a schema for now. These two schema match what is currently being returned, but I would recommend updating the published Open Api Spec and then updating these tests to use what we publish

Testing?

• these tests can be run locally with the existing shell script: ./scripts/run-local-tests.sh

[anayeaye]

@stephenkilbourn I'm stumped by the error. I see the branch is up to date with main and that the action has been retried a few times (I just launched another try with debug logging enabled, though).

[anayeaye]

OK it looks like the new openapi_schema_validator package dependency somehow results in us getting an upgraded version of moto==5.0.3). The successful ingest tests are running with moto==4.2.12.

1. We could try pinning the older moto that is working
2. OR we could update the ingest api tests for moto >=5.0.0 which seems to be something like replacing from moto import mock_dynamodb, mock_ssm with from moto import mock_aws and then updating the tests.

[anayeaye]

I wonder if we should be considering bumping stac-fastapi to a version >=2.4.4. It seems like some of the openapi issues this PR addresses here are maybe fixed for stac-fastapi in this PR?

[stephenkilbourn]

Should we attempt that upgrade in a separate branch and then test the updates there?

[stephenkilbourn]

In this PR, there are two validations against open API Schemas

1. First item returned from GET /collections against Collection Schema

changes made to the required properties from collection schema defined in https://api.stacspec.org/v1.0.0/collections/ :

        "required": [
          "stac_version",
-          "type",
          "id",
          "description",
          "license",
          "extent",
          "links"
        ],

Optional Properties not included:

-           "providers": {
-            "$ref": "#/components/schemas/providers"
-          },
-         "summaries": {
-          ...
-         }

For the Spatial extent schema, I did not included the optional crs property.
For the Temporal extent scema, I did not include the optional trs property.

2. First item returned from GET collections/noaa-emergency-response/items against feature schema defined in https://api.stacspec.org/v1.0.0/ogcapi-features/

No changes made from stac definition

[smohiudd]

@stephenkilbourn, shouldn't all our collections have the "type" properties? Was there a returned collection that didn't?

[smohiudd]

Ok I see now that we're testing against this collection: https://github.com/NASA-IMPACT/veda-backend/blob/develop/.github/workflows/data/noaa-emergency-response.json

That collection isn't valid and doesn't align the with the minimum requirement for our current stac collections in staging. Should we update to include the following properties:

• providers
• type
• extensions

In that case we would't need to modify the the V1.0.0 collection schema

[smohiudd]

Can we use the published STAC collection and features schemas instead of creating our own here?

[stephenkilbourn]

Yes, working on that for the next commit

[anayeaye]

One concern with using the seeded collection is that the hrefs are in a protected bucket that some implementations may not be able to access and the links direct to the staging catalog that we don't intend to persist.

The old noaa examples are public. Can we update the metadata for those to use for our tests?

[stephenkilbourn]

closing to move into simplified execution within #397