[go: up one dir, main page]

Version DAC API

Context

Closed - for more details see !8554 (comment 1383782588)

For more context about versioning DAC API and how this MR fits see #5437 (closed) and Versioning DAC API document. Builds the idea on top of !8508 (closed), but takes a different approach, thus I have opened a new MR instead.

This MR introduces versioning of the DAC API by prefixing existing endpoints with v0 and v1 API version.

V0 API (deprecated)

v0 consists of all the endpoints that we currently have. As such it will be used by the demo, and allows us to decouple the work on the new v1 api from the work on the demo. Compared to v1, v0 also consist of the the legacy endpoints GET /verify_signature and POST /store_preimage and is therefore API version used by legacy tezt test suite. The whole API consist of the following endpoints:

  • POST v0/store_preimage
  • GET v0/verify_signature
  • PUT v0/preimage (shared semantic by v0 and v1)
  • GET v0/preimage (shared semantic by v0 and v1)
  • PUT v0/dac_member_signature (shared semantic by v0 and v1)
  • GET v0/certificates (shared semantic by v0 and v1)
  • GET v0/missing_page (shared semantic by v0 and v1)
  • GET v0/monitor/certificate (shared semantic by v0 and v1)
  • GET v0/monitor/root_hashes (shared semantic by v0 and v1)

This API is already deprecated and will be removed as soon as old legacy test suite running only using v0 endpoints is migrated to the full-infrastructure test suite that runs only using v1 endpoints.

V1 API

Consists of the endpoints that will be released as a first public DAC API. Compared to v0 it replaces POST v0/store_preimage with PUT v1/preimage and removes GET v0/verify_signature.

As such the whole v1 API consist of:

  • PUT v1/preimage (shared semantic by v0 and v1)
  • GET v1/preimage (shared semantic by v0 and v1)
  • PUT v1/dac_member_signature (shared semantic by v0 and v1)
  • GET v1/certificates (shared semantic by v0 and v1)
  • GET v1/missing_page (shared semantic by v0 and v1)
  • GET v1/monitor/certificate (shared semantic by v0 and v1)
  • GET v1/monitor/root_hashes(shared semantic by v0 and v1)

Any backwards incompatible changes to existing v1 endpoints should result in major version upgrade (v2) once v1 is released.

Note to reviewers:

This MR does:

  • Minor code improvements (first two commits)
    • Adds a missing license
    • Removes redundant register_get_verify_signature registration from Coordinator mode
  • Introduces API module for versioning endpoints
  • Version API by two version v0 and v1
    • Since versioning api was done by prefixing all endpoints with version_rpc_arg, incremental (commit by commit) migration of endpoints to versioned API was not possible. The server registration would complain since the version_rpc_arg of the endpoint that was refactored fist would capture first part of the URI of the other endpoints. This could be fixed by having e.g. / api /: version_rpc_arg / [suffix] instead of /: version_rpc_arg / [suffix] at the cost of introducing api prefix. I don't think this was desirable. As a consequence 7b4ccba8 could not be made more atomic :/ (apologize to the reviewers)
  • Makes sure that tezt test suites are running using endpoints from the same API version.

Follow-up MR:

  • Add automatic API documentation (via swagger integration)
  • Remove legacy test suites, followed by removing v0, followed by removing legacy mode
  • Make tezt test suite parametric via the api version (to be discussed - see)

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

Loading