Add block types REST API.

[spacedmonkey]

Description

Add a simple REST API to allow get registered Block types.

How has this been tested?

The REST API request a logged in user to have edit_post capability.
APIs

• __experimental/block-types List of all blocks
• __experimental/block-types/<namespace>/<block_type> ie __experimental/block-types/core/post-author". Get details on a single block type
• __experimental/block-types/<namespace> ie __experimental/block-types/core . Get all blocks in a single name space.

fixes #2751
Trac ticket: #47620

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[spacedmonkey]

CC @kadamwhite for visibility.

[aduth]

Regarding the question at #2751 (comment):

Can anyone interested please take a look and see if this REST API has the required fields and data. Remember we can add fields later.

I don't know that it's been audited for accuracy lately, but the original Block Registration RFC might be a good source of properties expected to be needed?

https://github.com/WordPress/gutenberg/blob/master/docs/rfc/block-registration.md#block-api

@gziolo has been working on some of the specifics around block.json and may know more.

[spacedmonkey]

@aduth Worth noting the current fields that are in this API are based on what is currently register when you register a block on the PHP. I have a ticket in trac in #48529. This PR will only cover the existing fields for now. Adding the extra fields will covered in another PR or core patch.

[gziolo]

@aduth Worth noting the current fields that are in this API are based on what is currently register when you register a block on the PHP. I have a ticket in trac in #48529. This PR will only cover the existing fields for now. Adding the extra fields will covered in another PR or core patch.

Yes, we discussed it already. The work was divided into two parts on Trac and this one covers what we had before on the server before we started introducing block.json. It aligns with Block Registration RFC. is_dynamic is the only property that wasn't included there but it's fine as this is something that we use on the server only.

__experimental/block-types?namespace=<namespace> ie __experimental/block-types/?namespace=core . Get all blocks in a single name space.

I don't know what are patterns used for other endpoints in core, but I'm curious why not use __experimental/block-types/<namespace>?

[TimothyBJacobs]

I don't know what are patterns used for other endpoints in core, but I'm curious why not use __experimental/block-types/?

+1 to this pattern.

[spacedmonkey]

@aduth @gziolo Can either of you review this PR. A lot of work as gone into it and no eyes are on it yet.

[aduth]

@gziolo Anything you think is needed here, functionally-speaking?

[aduth]

Would we plan to include unit tests here? Or later in the experimental lifecycle?

[gziolo]

Anything you think is needed here, functionally-speaking?

I had some minor comments but nothing blocking. As far as I remember there was a follow-up on Track that adds the rest of block fields/properties.

[TimothyBJacobs]

Overall looks good, I'd really like to see tests on the prepare item with the different supported properties.

[spacedmonkey]

Overall looks good, I'd really like to see tests on the prepare item with the different supported properties.

@TimothyBJacobs Do you need these now before approval or before core merge?

[TimothyBJacobs]

I'd prefer to have them now, without them it is hard for me to tell if they are actually outputting what is expected.

[spacedmonkey]

I'd prefer to have them now, without them it is hard for me to tell if they are actually outputting what is expected.

@TimothyBJacobs Does this test cover prepare? https://github.com/WordPress/gutenberg/pull/21065/files#diff-c43bb246f80bf07e6c00d6fdb3427794R129-R149

[TimothyBJacobs]

That covers when invalid data is provided, but not the positive case.

[spacedmonkey]

That covers when invalid data is provided, but not the positive case.

Tests added for positive case. @TimothyBJacobs

[aduth]

I notice that, despite the fact the type is assigned as 'object', when the default value is returned by the endpoint, it is returned as a JSON array [] instead of {}. Having dealt with this in the past, I considered if casting it (object) array() would be enough, but it appears to make no difference.

Do you know if there's some way to force the default to return as an object?

[TimothyBJacobs]

Yeah this is an aggravating issue and there isn't a great way to do it. What can be done is check if attributes is empty in prepare_item_for_response and set an empty object instead, but I really don't like that because it means that the attributes property will sometimes be an array and sometimes be an object.

It is something I'd like to fix at some point, I'll try taking a look at this for 5.5.