We discussed how to approach the implementation of post, comment, term, and user meta in the REST API and came up with a few areas to focus on.

How to determine if meta is public

WordPress core currently contains the concepts of protected and authenticated meta. These may be useful to us when determining what to publicly expose in the REST API.

• If the first character of a meta key is _, meta is considered protected.
• If an auth callback is provided, meta passes through that auth callback, though isn't necessarily treated as protected.
• If the first character of a meta key is not _ and no auth callback is provided, meta is treated as public.
• There is also an is_protected_meta filter to override is_protected_meta().

Using register_meta() doesn't seem to be common among developers, so it's hard to rely on the current "publicness" of the meta. It's possible that we can treat meta as public in its current state. It's also possible that we'll need to add a specific argument for registering meta as public rather than as its default of unprotected. If we do add a specific argument, this may be show_in_rest to mirror register_content_type().

A piece to keep in mind is the existence of the_meta() (since 1.2.0), which can be used by a theme to output all currently unprotected meta in a list.

• Action: Search plugin directory to determine how register_meta() is currently being used.
• Action: Search plugin/theme directory to determine if/how the_meta() is currently being used.

Enhancing register_meta()

We determined that it would be useful to expand the scope of register_meta() a bit so that specific information about that meta data could be registered, similar to register_content_type().

This information should probably include the expected data type (string, int, etc...) and the description so that a more proper JSON Schema for the endpoint could be provided.

If it's determined that we need a more explicit way of registering the publicness of meta, this could be provided as well.

Any enhancements to register_meta() are beneficial to core as a whole and not entirely REST API specific, though type and description will help directly.

• Action: Open a core ticket to discuss enhancements to register_meta().
• Action: What other data should be provided with register_meta()?

How to expose meta in the API

Once we can determine the publicness of meta, we should be able to query for all of the public meta in a way that can be attached to an endpoint automatically. As mentioned before, the_meta() is available for themes to output a list of all unprotected meta. There is likely room for get_registered_meta(), which would not only return all of the public meta key/values, but also the meta for the meta—data type, description, etc... so that it can be reliably used via the API.

Ideally, for meta to appear in an endpoint, it should be registered so that the proper metadata for that meta can be provided.

Related tickets: #1425 (Primary), #1129, #1144.