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

 Replying to [comment:54 schlessera]:
 > I still recommend looking at the '''concept''' you want to model, not
 how its data happens to be stored.

 I agree. The concept is that a post is being saved and a revision is being
 (auto)created. The only difference between a `save` and an `autosave` if
 that the latter employs additional server logic when creating the
 revision.

 > Putting two models into the same endpoint because their data happens to
 be saved in the same way...

 These are not different models. It is the same model with the same data
 performing the same action of saving a post to the database.

 > As soon as they need to diverge again (posts needing to do something
 autosaves shouldn't, or vice-versa) you're facing a big problem again. You
 could for example imagine autosaves being stored as incremental diffs in a
 separate table through a later optimization.

 Wouldn't that depend on the server's "business logic"? It depends on it
 now. We auto-create revisions on each save. If these revisions are to be
 moved to a different method of saving, should we deprecate the revisions
 controller and stop auto-creating them? :)

 It doesn't seem likely for revisions to be stored as incremental diffs in
 a different table, unless perhaps we drop MySQL and move to git for
 storage :) Then we will drop the concept of revisions altogether and won't
 need to flag the autosave revisions.

 > That's why I recommend a separate `autosaves` endpoint, not some
 trickery with posts or revisions.

 The problem we seem to be stuck on is that '''autosaves do not exist'''
 outside of posts and revisions. Frankly I don't care much how DRY or non-
 DRY another controller may be, as long as it is logical, and easy to
 understand how it works and why.

 > ...but the actual public API should cleanly separate the concepts, not
 let the current technical implementation bleed through.

 That's exactly my point too :) The concept is that a post is being saved
 and a revision is being auto-created. There is a different server logic
 when this is done directly by the user or is triggered automatically by
 the client.

 I'm not sure how to stress this more: '''autosaves are not a different
 concept of saving'''. They are '''identical to "standard" saves'''. The
 difference is in the logic that auto-creates the post revisions.

 In any case, we have two patches that work well here:
 - One adds the specialized revision logic to the existing posts and
 revisions controllers.
 - The other introduces a new controller that partially duplicates the
 posts and revisions controllers and performs identical actions, but
 introduces different end points.

 This ticket has been "simmering" for over a month now and is urgent. Can
 we please get on the same boat, pick a patch and commit it already? :)

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