Add Datastore API use event(s)

[swirtSJW]

User Story

In order to make it possible for external modules to subscribe to events for notifications or tracking use, it would be nice to have Events emitted for API calls.

Detailed Feature Description

Must do:

This one is critical because it would reflect interacting with the dataset page or the querying it.

• Dispatch DkanDatastoreEvents::API_QUERY_RESOURCE at the conclusion of Drupal\datastore\Controller\QueryController::queryResource (/api/1/datastore/query/{identifier})

High value:

• Dispatch DkanDatastoreEvents::API_QUERY at the conclusion of Drupal\datastore\Controller\QueryController::query (/api/1/datastore/query)
• Dispatch DkanDatastoreEvents::API_QUERY_DOWNLOAD at the conclusion of Drupal\datastore\Controller\QueryDownloadController::query (/api/1/datastore/query/download)
• Dispatch DkanDatastoreEvents::API_QUERY_RESOURCE_DOWNLOAD at the conclusion of Drupal\datastore\Controller\QueryDownloadController::queryResource (/api/1/datastore/query/{identifier}/download)
• Dispatch DkanDatastoreEvents::API_QUERY_RESOURCE_??? at the conclusion of Drupal\datastore\Controller\QueryController::queryDatasetResource (/api/1/datastore/query/{dataset}/{index}). I am not sure what to call this one because I do not know how it differs from (/api/1/datastore/query/{identifier})
• Dispatch DkanDatastoreEvents::API_QUERY_RESOURCE_???_DOWNLOAD at the conclusion of Drupal\datastore\Controller\QueryDownloadController::queryDatasetResource (/api/1/datastore/query/{dataset}/{index}/download)
• Dispatch DkanDatastoreEvents::API_QUERY_SQL_QUERY at the conclusion of Drupal\datastore\SqlEndpoint\WebServiceApi::runQueryGet' (/api/1/datastore/sql)
• Dispatch DkanDatastoreEvents::API_QUERY_SQL_QUERY at the conclusion of Drupal\datastore\SqlEndpoint\WebServiceApi::runQueryPost (/api/1/datastore/sql). I think we can capture both get and post with the same event.

Possible other helpful events

I am not sure if any of these are needed at this time. Maybe they go in a follow-up ticket??

• Drupal\datastore\Controller\ImportController::delete (/api/1/datastore/imports/{identifier})
• Drupal\datastore\Controller\ImportController::deleteMultiple (/api/1/datastore/imports)
• Drupal\datastore\Controller\ImportController::summary (/api/1/datastore/imports/{identifier})
• Drupal\datastore\Controller\ImportController::list (/api/1/datastore/imports)
• Drupal\datastore\Controller\ImportController::import (/api/1/datastore/imports post)
• Drupal\common\Controller\OpenApiController::getVersions
• Drupal\common\Controller\OpenApiController::getComplete (/api/1/datastore)
• Drupal\datastore\Controller\QueryController::querySchema (api/1/datastore/query/schema)

Problem and Motivation

See user story

Target Audience

• End Users
• Developers
• Administrators
• Other

Possible Implementation

No response

Acceptance Criteria

No response

[TheETupper]

@beeyayjay @janette do you have any feedback on this?

[TheETupper]

Use the metastore page view

[TheETupper]

It would be interesting to see what is being downloaded. See https://healthdata.gov/ for example

[janette]

For naming purposes I think using 'datastore' and 'metastore' in the event name would keep it clear which events belong to each.
And using /api/1/metastore/schemas/dataset/items/{datasetUUID} to track interacting with the dataset page.

[swirtSJW]

For naming purposes I think using 'datastore' and 'metastore' in the event name would keep it clear which events belong to each.

I think that name spacing is covered by the event classname that you have to use when dispatching or subscribing to the event
DkanDatastoreEvents::API_QUERY
vs
DkanMetastoreEvents:API_QUERY

[dafeder]

Some thoughts --

• I don't think we want events for the OpenAPI stuff, since that already has a plugin system for overriding things. If it doesn't provide the level of control needed we can revisit but I generally favor plugins over events when either will work.

• I would not recommend discreet events for "reglar queries" vs "resource queries". These are IMO essentially just aliases for each other. If we do this ee should have one "query" event that communicates the context, params passed etc. I'm not convinced its necessary to have a separate event method for downloads either? I just think in most cases we're talking about listeners that you'd want to ping for any one of these and it will be more efficient to just share a single method and provide the context.