I'm wondering if the primary object can be a dataset, then what kind of flexibility would we like to have?

A combination of vector and raster collections?
- /datasets/{cool_dataset_name}/collections/{my_awesome_vector_collection}/items (WFS3 implementation or subset from remote WFS3)
- {my_awesome_vector_collection} has a collection_type=vector property
- example: http://geo.weather.gc.ca/geomet-beta/features/collections/hydrometric-daily-mean/items/
- /datasets/{cool_dataset_name}/collections/{my_awesome_raster_collection}/cogs ( COGs bucket server or subset from remote collection. Here a collection can be also described by a STAC specification)
- {my_awesome_raster_collection} has a collection_type=raster property
Just one of the two above with a property for being distinguished?
- /datasets/{cool_vector_dataset_name}/collections/{my_awesome_collection}/items
- /datasets/{cool_raster_dataset_name}/collections/{my_awesome_collection}/cogs
- {cool_vector_dataset_name} has a dataset_type=vector
- {cool_raster_dataset_name} has a dataset_type=raster

Open mind to different vision/model and happy if this work can be started. Also a great tool to collaborate can be spotlight

Based on current state of the OGC service standards design patterns and the resource oriented architecture, possible option for review/comment:

Principles

a dataset is either a vector (feature), grid (raster), or virtual (i.e. a process)
GeoNode supports the concept of themes (tag, ISO topic category). We can have the concept of a default theme (default or -)

Example dataset endpoints

/geonode/api/v1.0/features/collections <-- list all feature collections
/geonode/api/v1.0/features/collections/<theme> <-- list all feature collections from a given theme
/geonode/api/v1.0/features/collections/<theme>/roads/items <-- get features
/geonode/api/v1.0/coverages/collections <-- list all coverages
/geonode/api/v1.0/coverages/collections/<theme> <-- list all coverage from a given theme
/geonode/api/v1.0/coverages/collections/<theme>/landsat8/rangeSet <-- get coverage with HTTP Range request (COG) if specified
/geonode/api/v1.0/processes <-- list all processes
/geonode/api/v1.0/processes/foo-process/jobs <-- execute process via HTTP POST (returns HTTP 201)