Thanks for taking a look at this @spacedmonkey, but as I mentioned in the original issue, I'm not in favor of this at the moment. Just because something is stored as a CPT does not mean it should be exposed as a base class of WP_REST_Posts_Controller. There is a lot of functionality there that we are not interested in.

Additionally, for instance, if we are to integrate the customizer into the REST API, I don't expect customizer changesets to be implemented via the posts controller either.

Fundamentally, the goal of the REST API is to provide the most appropriate interface for each resource type, not to shoehorn all types into an existing type.

If we want to introduce more advanced functionality in the future, we can, but there isn't a need for it now. Additionally, our building blocks don't necessitate inheritance. Things like meta are designed to be able to be pulled in via the WP_REST_Meta_Fields helpers.

I don't understand this. I believe this PR deminstrates that perfectly, why this should use the post controller. The interface is exactly the same, global styles are requests via their ID.

The only difference here, is a little field mapping. Which this class does. There are already two other examples of where we do something similar. The WP_REST_Blocks_Controller, overrides some of the fields and the WP_REST_Menu_Items_Controller that does field mapping as well. I don't see the difference here?

This PR, adds functionality, like

• Taxonomy querying
• Meta handling
• Delete endpoint
• Create endpoint

All with the less code and extending an existing endpoint. It means also, that we have less code to maintain and any other improvements will filter down to this endpoint.

I have yet to have anyone explain why this endpoint HAS to be different. Can you provide some more context to this @youknowriad

Similarly, by is the templates post type controller registion. See #36095