[wp-trac] [WordPress Trac] #43316: REST API: Support autosaves

[WordPress Trac]

#43316: REST API: Support autosaves
-------------------------------------------------+-------------------------
 Reporter:  kraftbj                              |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  5.0
Component:  REST API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:  rest-api
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by rmccue):

 I've been watching this ticket for a while and thinking about it; it's a
 tough problem to crack. Trying to summarise what I think the difficulties
 and decisions to make are:

 I think the key thing we need to get at is defining what an "autosave" is.
 @azaozz mentions 'autosaving is "trigger saving a post"'; how does
 autosaving differ from a regular update in that regard? When would I want
 to differentiate a manual save from an autosave?

 To me, the basic logic flow seems something like:

 1. User starts editing: this creates a sort of "future revision" that
 they're working on, forked from the original post
 2. User makes some changes: this updates the "future revision" that
 they're working on
 3. User hits save: this "commits" the "future revision", and saves the
 original post

 The difference between 2 and 3 is why we need the distinction between
 manual saves and autosaves. Only 3 should create a "real revision",
 whereas 2 is just internal behaviour. Does this seem accurate?

 IMO we need to get a concrete mental model of how this works, independent
 of the actual internal behaviour.

 (We never really used it, but the [https://github.com/WP-
 API/proposals/blob/master/0000-template.md template in the proposals repo]
 would be useful to establish a design doc for this.)

 I quite like the concept of treating autosaves as actual future revisions
 from the client's perspective. Both revisions and autosaves share the same
 logical underpinnings of being an alternative version of the post with
 changes, and the post can be updated to use that version's data instead
 (whether restoring a revision or "committing" an autosave). I'm not
 certain on the actual implementation of autosaves, but it seems like they
 use revisions under the hood?

 The flow I'm thinking would be something like:

 * User starts editing: `POST /wp/v2/posts/{id}/revisions` creates a new
 "future revision"
 * User makes some changes: `PUT /wp/v2/posts/{id}/revisions/{rev_id}`
 updates this "future revision"
 * User hits save: `POST /wp/v2/posts/{id}/revisions/{rev_id}` commits the
 "future revision"

 The main change here would be this idea of updating a "future revision",
 which would avoid the massive-amounts-of-revisions problem. It would be
 entirely up to the client to control the autosave behaviour and when to
 commit, which is definitely the right choice to make IMO. (This may
 require changes to the underlying API in WP, as I'm not sure what's
 supported around this.)

 If we don't build it into the revisions endpoint, I'm +1 on a separate
 autosaves endpoint, which I think makes more sense than having a flag in
 regular updates. I'm not sure the the current behaviour in
 [attachment:43316.12.diff] makes sense though; you POST to /autosaves,
 which updates the actual post?

 Also, I am -1 on this "detect how much has changed" idea; that seems like
 a pretty fundamental change, and not one that we should make in the
 context of this issue.

 > (I've forgotten how we support "restoring" revisions).

 We never actually ended up including this ability, since IIRC we thought
 it may someday interfere with autosaving. :)

 I'd propose that we go with the original design, which is `POST
 /wp/v2/posts/{id}/revisions/{rev_id}` restores a revision; this fits with
 the same action "committing" a "future revision" as well.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43316#comment:59>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform