[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 danielbachhuber):

 Offering some perspective from a fresh pair of eyes. Feel free to discard
 any feedback you consider unqualified, given I haven't been following the
 conversation closely.

 From the user's perspective, I see two goals:

 1. I should never lose what I'm currently working on (autosaves).
 2. I should be able to see, and restore, my history of edits (revisions).

 If we agree these are two ''distinct'' goals, then it would logically make
 sense to have two separate REST API endpoints because there are two
 distinct sets of behaviors:

 1. The autosaves endpoint is read/write. There is only one 'autosave'
 resource per user. A client can create an autosave for a user, retrieve
 the autosave for the user, and retrieve all autosaves for all users.
 2. The revisions endpoint is read-only. Revisions are created by server
 when a resource is saved. The client can only retrieve all revisions (I've
 forgotten how we support "restoring" revisions).

 And then we get in to the programmatic implementation of the abstraction:

 * It seems magical to create a revision based on some algorithm applied to
 the saved data. I'd think this logic makes more sense client-side; let the
 client decide whether to perform a full save or an autosave.
 * Similarly, if revisions are only created when a post is fully saved,
 then I think it makes sense to keep that distinction in the client-side UX
 (i.e. you hit the "Save" button to create a revision).
 * Because autosaves are user-specific, paths and supported operations
 would be:
     * `GET /wp/v2/posts/<post-id>/autosaves` - List all autosave objects.
     * `POST /wp/v2/posts/<post-id>/autosves` - Create a new autosave
 object.
     * `GET /wp/v2/posts/<post-id>/autosaves/<user-id>` - Get the autosave
 object for a specific user.
 * I don't think developers should have to opt-in to autosaves using
 `post_type_supports()`. Server-side (and client-side) autosave should be a
 default feature of the WordPress UX.

 For a fun thought experiment, or dark rabbit hole, imagine revisions and
 autosaves for individual blocks :)

 Let me know if any of this is off-base, or if there's additional input I
 can provide.

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