Expose rendered blocks in REST API endpoint for Reusable Blocks

[westonruter]

I noticed an API discrepancy between REST API post endpoints and the blocks endpoint: the latter lacks the raw and rendered properties of the former. Instead, it contains a flat title and content:

gutenberg/lib/class-wp-rest-blocks-controller.php

Lines 110 to 119 in 4fd5c20

	'title' => array(
	'description' => __( 'The block’s title.', 'gutenberg' ),
	'type' => 'string',
	'required' => true,
	),
	'content' => array(
	'description' => __( 'The block’s HTML content.', 'gutenberg' ),
	'type' => 'string',
	'required' => true,
	),

Compare with other endpoints in core for where title and content are defined with raw and rendered. (Granted, the title is less key to have rendered for Reusable Blocks.)

For parity with the other core endpoints, it would seem logical to include raw and rendered. But also this would be very useful. Consider case of creating a reusable block and then wanting to be able to share the URL of the block for embedding on other site such as via an iframe. If there was a rendered value that used the block's render_callback for dynamic blocks and which applied the_content filters, then you could reuse the Reusable Blocks outside of your WordPress install.

Allowing the rendered output of a block to be exposed in the REST API could also be very useful in a site as well. Consider a case of a site that has a 10 minute TTL cache in Varnish, but there is a Latest Posts block that they want updated every minute. If the Recent Posts block were a Reusable Block and could be accessed from the REST API, then an ESI could be used to incorporate the block's contents on the edge without requiring WordPress to re-generate the entire page. This approach could also be used on the client when a service worker is installed, as it could compose a page with composite streams. It could be used to compose pages client-side using structured block templates in #3588.

We'd need to be careful about permissions. We wouldn't want someone to create a Reusable Block with sensitive data in it and then have it unexpectedly exposed.

To illustrate further, if I create a Reusable Block for the Latest Posts block, there is a request to https://example.com/wp-json/wp/v2/blocks/8145 when I open the editor, and the response is:

{"id":8145,"title":"Untitled Reusable Block","content":"<!-- wp:latest-posts \/-->"}

However, I'd love to see a response instead like:

{
	"id": 8145,
	"title": {
		"raw": "Untitled Reusable Block",
		"rendered": "Untitled Reusable Block"
	},
	"content": {
		"raw": "<!-- wp:latest-posts \/-->",
		"rendered": "<ul class=\"wp-block-latest-posts aligncenter\"><li><a href..."
	}
}

REST API endpoints originally introduced in #2503.

/cc @noisysocks

[aduth]

Related: #7453 (removes custom endpoints, promotes on base posts controller)

[noisysocks]

Good catch, @westonruter. Thanks for opening an issue.

As @aduth mentioned, it's likely we'll eliminate the custom controller altogether which means we'll get parity between the two REST endpoints for free.

[mtias]

@noisysocks what's the status of this? Is it obsolete now that it's using a regular post controller?

[aduth]

This should be considered as fixed by #10751, which drops the custom endpoint in favor of the existing posts endpoints.