Align better with WFS3

[cholmes]

In stac sprint 2 we decided to align with WFS3 for the dynamic API. It is not required to implement WFS3, the only requirement is the search/stac endpoint, which it does. But it makes some additional decisions that can lead to some confusion.

This issue defines a baseline of fixes to be less confusing with WFS. In another issue I'll lay out what would be needed for WFS compliance.

So the first thing to do is to make /collections/ endpoints. The mechanics for these is in place, it's just a constraint on the cross provider search that sat-api offers. So add in

https://sat-api.developmentseed.org/collections/sentinel-2-l1c/items/ which should operate the exact same as https://sat-api.developmentseed.org/search/stac?cx:id=sentinel-2-l1c

And

https://sat-api.developmentseed.org/collections/landsat-8-l1/items/ should work just like https://sat-api.developmentseed.org/search/stac?cx:id=landsat-8-l1

Any additional new type of data (MODIS, etc) should get its own collections/{name}endpoint.

The other bit to shift is the current /collections/ endpoint. This right now returns a list of all the jsons of a stac-collection, as specified https://github.com/radiantearth/stac-spec/blob/dev/extensions/stac-collection-spec.md These are referred to by the stac Items, and get joined on the fly for the full item output.

As discussed on gitter, these should shift to be 'description' and sit beside the /items/ So:

https://sat-api.developmentseed.org/collections/sentinel-2-l1c/description should return exactly what https://sat-api.developmentseed.org/collections?cx:id=sentinel-2-l1c does now, and landsat would be equivalent.

Those endpoints are the core. If we want a way to list all the descriptions available then could use an endpoint like https://sat-api.developmentseed.org/collections/descriptions

This should be the core for sat-api to be less confusing with WFS. I'll file another issue which should get us quite close to WFS3 compliance - mostly just linking the endpoints together.

[matthewhanson]

@cholmes I've implemented these changes in the current sat-api, with the exception of "description" I call "definition". Easy enough to change.

Also, /collections/ returns all the collections, like before just because I needed to have a way to return all of them, but I like /collections/descriptions (or definitions).

Once we decide on description or definition I'll make that change, add in the new endpoint for the collections definitions and close this issue.

[matthewhanson]

Ok, I've kept this as 'definition'