Skip to content

Draft: DAC: Prefix endpoints with API version

Martin Tomazic requested to merge martin@version_dac_api_v1 into master

Context

Fyi !8554 (closed) will likely replace this MR (!)

For more context about versioning DAC API and how this MR fits in -> see #5437 (closed).

This MR prefixes the endpoints that will be supported via the first release (and also used during the demo) with v1 prefix. As such this endpoints will be binding from now on and may only be changed in the backwards compatible manner. Modifying existing RPC, will require a major version upgrade.

The current V1 API will consist of the following endpoints:

  • PUT v1/preimage
  • GET v1/preimage
  • PUT v1/dac_member_signature
  • GET v1/certificates
  • GET v1/missing_page
  • GET v1/monitor/certificate
  • GET v1/monitor/root_hashes

Note that legacy GET /verify_signature and POST /store_preimage will not be released as part of V1 API and consequently were not prefixed. This means that current legacy test are running as a mix of before-mentioned endpoints and and V1 endpoints. Whether this is problematic or not has been discussed here.

As a followup, I suggest two axis of work:

  1. Modularize internal codebase and test suite via V1 modules. This modules will be pre-pended with banner documentation that explains the binding contract of V1 API and that it's modification should be taken extreme care of (backwards compatibility only)
  2. Migrate legacy test suite to ful_infrastructure so that GET /verify_signature and POST /store_preimage endpoints can be removed and with it eventually also the whole legacy mode.

Manually testing the MR

CLI should pass.

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR
Edited by Martin Tomazic

Merge request reports