Use wp/v2/types and wp/v2/taxonomies responses to determine post type and taxonomy namespaces

[greatislander]

Is your feature request related to a problem? Please describe.
Currently, there is no way to load post types or taxonomies in namespaces other than wp/v2 as all PHP and JS functions and methods for loading and saving data via the REST API assume the wp/v2 namespace. This is related to #3462. It also has implications for future-proofing Gutenberg for core entities. In the event that the WordPress REST API bumps to v3 at some point in the future, dozens of files will have to be updated to reflect the new namespaces for each entity (post type or taxonomy).

Describe the solution you'd like
In both PHP and JS functions and methods for loading REST API data, the wp/v2/types and wp/v2/taxonomies endpoints are retrieved. These endpoints contain a wp:items link for each entity in the responses’ _links:

"post": {
	"description": "",
	"hierarchical": false,
	"name": "Posts",
	"slug": "post",
	"taxonomies": [
		"category",
		"post_tag"
	],
	"rest_base": "posts",
	"_links": {
		"collection": [
			{
				"href": "https://wordpress.org/wp-json/wp/v2/types"
			}
		],
		"wp:items": [
			{
				"href": "https://wordpress.org/wp-json/wp/v2/posts"
			}
		],
		"curies": [
			{
				"name": "wp",
				"href": "https://api.w.org/{rel}",
				"templated": true
			}
		]
	}
}, 

As per some discussion in #core-restapi, this data in _links is the canonical way of getting the namespace for an entity from the REST API.

In both the functions I linked above, the wp/v2/types and wp/v2/taxonomies endpoints could be retrieved and used to determine the namespaces for the entities being fetched via the REST API (in fact, the wp/v2/types response is already used to determine the rest_base in loadPostTypeEntities() and loadTaxonomyEntities() functions, so using it to determine the namespace as well would be a fairly straightforward change).

Describe alternatives you've considered
There’s no alternative to loading namespaced post types or taxonomies via the REST API that I’m aware of. If there are no objections, I have a branch in progress which will implement this change and I can open a pull request for review.

[danielbachhuber]

I'm still not convinced Gutenberg should formally support non-wp/v2 namespaces yet, if ever. There hasn't been a reason presented yet that's compelling over its alternatives.

Previously #3462 (comment)

[kadamwhite]

I can appreciate @greatislander's use-case -- we can currently use filters to arbitrarily modify the data returned by core endpoints, and extending the posts controller into a custom class that you manage through its own namespace I see as a beneficial way to reign that in by declaring that a specific filtered response structure should be unchanged at that namespace version. External applications don't have any way to introspect within WP to understand the shape of the content, so it's safer from an integration standpoint to manage your own versioning.

Providing that your post type does not override any of the core posts controller functionality that would be needed for use with gutenberg, none of that stuff about versioning should preclude the use of Gutenberg. I like where #2457 is headed, allowing a custom post type with its own controller to opt back in to Gutenberg through supporting the 'block-editor'.

From a strictly code-oriented standpoint, I frown on the hard-coding of wp/v2 anyway: this is what our links are for, and we should be using them instead of the current logic in loadTaxonomyEntities().

What I'd like to see come of this is for #2457 to move forward, and for our logic in loadTaxonomyEntities to use the resource links to build that base URL. With those two things in place I think we'd be very close to fixing this.

[danielbachhuber]

#8682 is related because it's another implicit expectation of functionality that may or may not be available on non-wp/v2 routes.

[danielbachhuber]

Closing this for now as maybelater.