Persistence layer

Background

Whilst we'll be doing optimistic updates to the UI for the content editor, in the background, the decoupled layout builder will need to communicate with Drupal to update the state of the configured layout.

Because this should be compatible with the existing layout builder UI, we should retain and respect the current data model. This is primarily because moving to a different data structure would require an update path and would be too ambitious for this pitch/proof of concept.

Proposed resolution

Create an OpenAPI spec for the persistence layer. The MVP will include the following endpoints:

• Choose section
• Add section - superseded by put layout
• Remove section - superseded by put layout
• Choose block
• Add block - superseded by put layout
• Update block - superseded by put layout
• Remove block - superseded by put layout
• NEW✨ - get layout
• NEW✨ - put layout
• NEW✨ - discard layout
• NEW✨ - revert layout to defaults
• NEW✨ - save layout

These will mirror existing HTML endpoints from layout builder

Create JSON equivalent versions of these routes. Some of these routes will serve information for the decoupled layout builder (e.g. choose block/section), whilst others will exist to perform mutations of the configured layout on the Drupal side.

Out of scope but for future consideration:

• Configure section - this will happen client side
• Move block - superseded by put layout