Skip to content

Including extra data in the API response to the front end

Robert Sinton requested to merge feature/extra_data_in_rest_exceptions into master

Added support for including optional extra data in the API response to the front end, in the case of raising a DF_REST_Exception.

  • Added a public property to the DF_REST_Exception class, and a matching parameter to set it.
  • Added a check for that property to handle_api_method_exception(), which will merge it into the response if there is anything in it.

Implications

  • This is yet another parameter to DF_REST_Exception. I've stuck it at the end of the list on the grounds that it won't be used often, but it's open for discussion. Maybe it should go before the 'previous' parameter?
  • There is no checking whether the extra data contains any of the other properties we would include in the response, e.g. result, errors, etc.

Setup

None

How to test

  • Use this when instantiating a DF_Rest_Exception, and then check that the specified data ends up in the API response to the browser.

This was written as part of refactoring some existing Art Money code, where a multi-step process might create a main DB record but then fail to create subsidiary ones. The error reports would include the ID of the main record, so that it could be injected into the form, and then subsequent retries would include that ID in the data submitted, and the back end would know to skip creating the main record this time (at least I think that's the intention). There are possibly better ways to achieve that particular goal, but I suspect there would be other circumstances where we would find this option useful anyway.

Edited by Robert Sinton

Merge request reports