At the moment, there is no official way to perform any actions before or after a record REST API request (or to be more precise, after a record CRUD operation has been committed to the database).
Sending signals at the end of each REST resource method would be a solution to this problem, and allow for such pluggable actions. The end result would be something like after_records_post, after_record_put, after_record_delete, etc.
The ugly part
Although this might be frowned upon since it's introducing the danger of a user of the module modifying the database state or creating side effects, it's a logical use case for when there is a need for sequential execution of actions. A common example is record indexing, where a created/modified/deleted record should be sent for the appropriate indexing operation on ElasticSearch, in order to appear or be removed from the search results. This would prevent the following pattern from happening:
POST /api/records
DB transaction started
Payload validated
Record with PID recid:1 created in transaction
Record sent for indexing
DB commit fails
GET /api/records
Record with PID recid:1 available in results
GET /api/records/1
404 Not found
(Another issue is the fact that signals have proven to be hard to debug, especially in complex operations (eg. deposit actions), so introducing more of them won't make things easier... This though is general issue that might need better handling on a global level, such as better documentation of signals or keeping a programmatically accessible registry of signals for debugging purposes)
At the moment, there is no official way to perform any actions before or after a record REST API request (or to be more precise, after a record CRUD operation has been committed to the database).
Sending signals at the end of each REST resource method would be a solution to this problem, and allow for such pluggable actions. The end result would be something like
after_records_post,after_record_put,after_record_delete, etc.The ugly part
Although this might be frowned upon since it's introducing the danger of a user of the module modifying the database state or creating side effects, it's a logical use case for when there is a need for sequential execution of actions. A common example is record indexing, where a created/modified/deleted record should be sent for the appropriate indexing operation on ElasticSearch, in order to appear or be removed from the search results. This would prevent the following pattern from happening:
POST /api/recordsrecid:1created in transactionGET /api/recordsrecid:1available in resultsGET /api/records/1404 Not found(Another issue is the fact that signals have proven to be hard to debug, especially in complex operations (eg. deposit actions), so introducing more of them won't make things easier... This though is general issue that might need better handling on a global level, such as better documentation of signals or keeping a programmatically accessible registry of signals for debugging purposes)