Servers with many collections

Discussed during the WFS 3.0 Hackathon:

The Core right now is designed for smaller amounts of collections. Issues with a large number of collections:

• The feature collections metadata response (/collections) may become large. This could be addressed by supporting paging and filtering in this resource. This could be done in an extension.
• The API definition can become very large, too, and computation intensive to compile, if each collection is listed as a separate operation. This could be addressed by using a parameter for the collection name, i.e. having only generic, parameterised /collections/{name} and /collections/{name}/items/{id} operations. Information about the available collections would then have to be obtained from the /collections operation. Another option could also be to support filtering of collections in the api operation.

The paths used above are based on #64.

Start by reviewing the WFS 3.0 Hackathon discussion and issue #64, then examine the /collections, /collections/{name}, /collections/{name}/items/{id}, and api resources described here. The issue needs an agreed design for handling many collections, including whether paging, filtering, or parameterised operations should be used; done would be a documented, accepted approach.