Issue Overview

When fixing #3167 with #3233 we opened a discussion on how to handle post revisions in the long run:

While it doesn't appear that it will prevent content filtering from being run, an alternative solution to limiting the size of the version history payload in the upcoming 4.9 release is to specify only the necessary fields on the API request:
e.g. /wp/v2/posts/4462/revisions?_fields=id

See: https://core.trac.wordpress.org/ticket/38131

@aduth: Yes, that would be one of the possible ways of improving performance here. I think it would still need more work to make sure that REST API call is triggered every time new post's content is saved. At the moment information about revisions doesn't get updated whenever a post is saved. This PR addresses it, too.

Yes, I'm aware of that, I'm just saying we may want to load the "last_revision_id" and "revision_count" in a separate endpoint instead of adding these as extra fields to the default POST endpoint. Because this change will change the result for everything and not only Gutenberg.

@youknowriad: it is another solution that would work. Again, we would need to find a way to refresh data each time post is saved.

@pento post data structure contains a list of categories or tags, why this is not the case for revisions? I'm sure there are reasons like we don't want to fetch everything and ruin performance. According to the documentation, we can pass context argument where one of the values is edit. It seems like a perfect match to our use case. So I would be happy to explore adding revisions to the REST API and enable it by default only in edit context.

Let's discuss here how we can improve the current solution - https://github.com/WordPress/gutenberg/pull/3233/files#diff-9dfc2b70ad1c71918441461179054b0bR386. REST API endpoint for post data is extended to serve also information about revisions. The downside of this approach is that it is now added to every REST API call that fetches post data.