Fix/add landing page links

[duckontheweb]

Related Issues:

• Landing page search link relation advertised with type application/json instead of application/geo+json #219
• Incorrect "conformance" link relation href in Landing Page #218
• Missing service-desc and service-doc link relations in Landing Page #217
• Missing "root" relation in Landing Page #216

Summary of Changes:

• Uses a module-scoped fixture to fetch the landing page within test_conformance so that we only fetch it once
• Adds parameterized tests for links related to the above issues
• Adds root and service-desc links to landing page
• Changes type of search link to "application/geo+json"

Questions:

• Should the "service-desc" rel type be added to stac-pydantic.links?
• Should the "application/vnd.oai.openapi+json;version=3.0" MIME type be added to stac_pydantic.shared?
  Opened Add OpenAPI MIME and rel types stac-pydantic#101 for both of these changes.
• Should we change the default OpenAPI endpoint to be /api to be in line with the recommendation in the STAC API spec?
  This is configurable in ApiSettings.openapi_url and defaults to /api
• UPDATE: Should I also include a fix to the /search endpoint "Content-Type" header for /search endpoint returns Content-Type header of application/json instead of application/geo+json #220? I'll do this in a separate PR since it seems like it might be a bit involved.

I plan to add the equivalent changes to the sqlalchemy app but was having some trouble getting those tests to run and I thought I'd get feedback on this first. I got these working and added the equivalent tests.

cc: @philvarner

[lossyrob]

Looks like this has some changes from #230 , we should merge that first and then update this branch.

[duckontheweb]

Looks like this has some changes from #230 , we should merge that first and then update this branch.

I cherry picked the makefile change to make the sqlalchemy tests run, but other than that these should be able to be merged independently.

[philvarner]

Should we change the default OpenAPI endpoint to be /api to be in line with the recommendation in the STAC API spec?

In some way, I would wish that you didn't change it, so that a prominent implementation would be doing something other than /api, which would allow us to more easily find clients who hardcode /api rather than discovering the URL from the root links.

[geospatial-jeff]

It might be worth removing the openapi / docs endpoints from the landing page because I don't think they will work with changes introduced in #147

[duckontheweb]

It might be worth removing the openapi / docs endpoints from the landing page because I don't think they will work with changes introduced in #147

They seem to be working okay on master right now. I'm serving up the pgstac dev app from the current master and the docs, redoc, and openapi.json endpoints are giving (what I think) are reasonable responses. Is there something in particular that might be broken about those?

cc: @geospatial-jeff

[philvarner]

I would recommend against removing them, even if they're not entirely accurate, as the link relation is required by stac api.

[duckontheweb]

I would recommend against removing them, even if they're not entirely accurate, as the link relation is required by stac api.

@philvarner To me the STAC API docs are a little fuzzy on this point. There's this sentence from the Core API docs...

This spec does not require any API endpoints from OAFeat or STAC API to be implemented, so the following links may not exist if the endpoint has not been implemented.

...and then in the Link Relations section (emphasis added)...

The following Link relations should exist in the Landing Page (root).

However, in reality, it seems like root, self, and service-desc must be present and child may be present. Maybe we should reorganize those links a bit for clarity or change the wording?

That aside, I agree we should keep the links even if they're not perfect, as long as they are not misleading.

[duckontheweb]

Should we change the default OpenAPI endpoint to be /api to be in line with the recommendation in the STAC API spec?

In some way, I would wish that you didn't change it, so that a prominent implementation would be doing something other than /api, which would allow us to more easily find clients who hardcode /api rather than discovering the URL from the root links.

I can see the usefulness of this from the client validation standpoint and I don't have a strong opinion on this, so I will go with whatever the consensus is. The thinking for changing it is that it seems like stac-fastapi is quickly becoming the de facto Python STAC API implementation, so it seems like it should follow best practices as closely as possibly.

[philvarner]

I would recommend against removing them, even if they're not entirely accurate, as the link relation is required by stac api.

@philvarner To me the STAC API docs are a little fuzzy on this point. There's this sentence from the Core API docs...

I agree that's not worded well. For one, that should be "shall" and not "should". (I shall fix it, if you should like)

Moving child out is a good idea.

[philvarner]

I can see the usefulness of this from the client validation standpoint and I don't have a strong opinion on this, so I will go with whatever the consensus is. The thinking for changing it is that it seems like stac-fastapi is quickly becoming the de facto Python STAC API implementation, so it seems like it should follow best practices as closely as possibly.

Definitely, stac-fastapi is that. Good point about following best practices

[duckontheweb]

I would recommend against removing them, even if they're not entirely accurate, as the link relation is required by stac api.

@philvarner To me the STAC API docs are a little fuzzy on this point. There's this sentence from the Core API docs...

I agree that's not worded well. For one, that should be "shall" and not "should". (I shall fix it, if you should like)

Moving child out is a good idea.

😆 I should!

[duckontheweb]

I can see the usefulness of this from the client validation standpoint and I don't have a strong opinion on this, so I will go with whatever the consensus is. The thinking for changing it is that it seems like stac-fastapi is quickly becoming the de facto Python STAC API implementation, so it seems like it should follow best practices as closely as possibly.

Definitely, stac-fastapi is that. Good point about following best practices

The OpenAPI endpoint is now configurable with ApiSettings.openapi_url and defaults to /api.

[duckontheweb]

@geospatial-jeff @lossyrob This is ready for another look-over