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

 Thanks @azaozz, @adamsilverstein. I'll reply to the few points I can
 easily comment on:

 > Here we are proposing that revisions are created whenever an autosave
 occurs and the content has changed not insignificantly. This expands the
 definition of autosaves and lets WordPress automatically track your
 changes over time versus keeping only a single backup (especially for
 published posts). This protects users by capturing a history of changes. A
 filter is provided to disable this behavior.

 Has this idea been validated as useful in the real world? Given the
 tendency of revisions to bloat the database, it seems like it might be
 worthwhile to verify this is a valuable feature for end users.

 Another way of considering: if autosaves create new revisions by some
 multiple (e.g. 5x), then it will change the UX of working back through the
 revision history.

 Other ideas: only keep the most recent five auto-saves as revisions, only
 create an auto-save revision every five minutes, etc.

 > What if you want to save your work in progress when updating an already
 published post?

 We need future revisions! But yeah, interesting question.

 > I'm not sure which makes more sense from pure "RESTfull" point of view:
 having a flag or having a separate controller that partially duplicates
 the `WP_REST_Posts_Controller`.

 If the shape of the data is the exact same, then we could co-opt the
 `status` attribute to trigger an auto-save (i.e. `status=auto-save`).

 If the shape of the data is different, then we need a different REST
 endpoint.

 REST is all about the resources: Posts, Users, Terms, etc. A Post has `id`
 and `title`, whereas a user has `id` and `name`. Because the data is
 shaped differently, they exist at different endpoints.

 ----

 Generally, in thinking about this more, I'd be leaning closer to one
 revisions endpoint that covers past and future revisions. We could handle
 write operations through `/wp/v2/posts` with special `status` attribute
 handling.

 Even taking a step back from this, it seems like it might make sense to
 produce a design document capturing all of the detail on how the
 endpoint(s) should behave, and write code once that's determined. Right
 now, it's difficult to understand the decisions and consensus through all
 of the Trac comments and patches.

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