Framework: Use a single way to call APIs: wp.apiRequest

[youknowriad]

This PR refactors API calls in Gutenberg to always use wp.apiRequest.
In addition to consistency, this makes it easier for third-party Gutenberg USAGE to use it without a WordPress backend and just provide an alternative implementation to wp.apiRequest

Testing instructions

• Test that saving/updating and removing posts works
• Test that adding/removing tags and categories works
• Test that embed blocks still work
• Test that saving metaboxes work
• Test that you can create/update and delete reusable blocks.

[notnownikki]

This breaks the embed blocks here.

With fetch, we get the error response from oembed back here as json, so this is where we deal with errors. With wp.apiRequest, we don't. So if anyone puts in a URL that we can't embed, we never get out of the fetching state and report the error to the user.

[youknowriad]

Good catch @notnownikki It should be fixed now.

[notnownikki]

👍 You beat me to the fix :) works as expected now!

[brandonpayton]

This is beautiful. I had no idea it was considered reasonable to not use wp.api.models.

[gziolo]

I like how you unified the way all API calls are handled. In particular, I love the fact that there is one way to trigger all calls. However, I'm not sold on the idea of leaving the details on how paths are created for the endpoints. This should be an implementation detail in my opinion. I would prefer having:

this.suggestionsRequest = wp.api.makeRequest( 'posts', {
	search: value,
	perPage: 20,
	orderBy: 'relevance',
} );

const makeRequest = ( endpointName, options ) => {
	const endpointMappers = applyFilters( 'api/endpointMappers',  {
		posts: ( { search, perPage, orderBy } ) = ( {
			path: `/wp/v2/posts?${ stringify( {
				search,
				per_page: perPage,
				orderby: orderBy,
			} ) }`,
		},
	} );
	// I assumed that the base path is prepended if not provided
	wp.apiRequest( endpointMappers[ endpointName ]( options ) );
};

over:

this.suggestionsRequest = wp.apiRequest( {
	path: `/wp/v2/posts?${ stringify( {
		search: value,
		per_page: 20,
		orderby: 'relevance',
	} ) }`,
} );

It would be definitely more work because you would have to define a separate mapping function for every single API endpoint. However, we could expose this configuration and make it extensible. This would allow overriding those mapping functions and give more control over how all those requests are handled.

I might be wrong in here because I'm not familiar with the code updated in this PR. So treat it as my own opinion. In fact, this PR is perfectly fine to be merged as it is once it is properly tested with someone who knows all the places we should look at.

[youknowriad]

@gziolo Actually, I'm totally on board with your idea, in fact, I think that should be the next step. This is more "in-between" approach unifying API calls without rewriting everything.

In your proposal, we'll have to specify all the models properly (independently from the WP models):

• Posts: What does a post mean for Gutenberg, what attributes it contains, what operations are allowed
• Taxonomies: Same
• Embeds: Same
• Saved Blocks: Same

This means a huge impact on the code base of Gutenberg because we're abstracting the backend entirely, which is good because it means offline support, WP agnostic but requires way more work. The unifying using wp.apiRequest is a middleground solution without too much impact.

An adventurous implementation can still achieve the exact same thing by mapping the WP paths instead.

[notnownikki]

I'd get behind that too. I'm trying to fix a situation where I need some abstraction between the API call and what the block does with it, so, happy to help out if we go this direction.

[gziolo]

In fact, this PR is perfectly fine to be merged as it is once it is properly tested with someone who knows all the places we should look at.

Just wanted to repeat that I'm more than happy to see it merged as it is :D

[gziolo]

An adventurous implementation can still achieve the exact same thing by mapping the WP paths instead.

I wouldn't describe it better in terms of overriding paths based on regular expressions. I agree it's totally doable 👍

[phpbits]

@youknowriad can wp.apiRequest get custom post meta value and update it? I would like to do this onChange action for my select field. Thanks!