[wp-trac] [WordPress Trac] #44862: Create REST API endpoints to lock, release and takeover post edition

[WordPress Trac]

#44862: Create REST API endpoints to lock, release and takeover post edition
-----------------------------+--------------------------------
 Reporter:  youknowriad      |       Owner:  timothyblynjacobs
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  5.0
Component:  REST API         |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  rest-api
-----------------------------+--------------------------------

Comment (by TimothyBlynJacobs):

 I don’t think we should just use an attribute on the post response. The
 status of a lock isn’t a property of the actual post entity, its a system
 on top of it. The semantics for post locking aren’t going to map super
 nicely to REST. And I don’t think we should impose this on the post
 endpoint.

 Necessary Functionality
 - Check if the post is locked
 - Aquire a lock
 - Update a lock
 - Take over a post
 - Nice to Have: Release a lock. This isn’t currently implemented, the lock
 will stay there until it expires.

 Simple Solution, not really REST semantics. I don’t think that’s
 necessarily an issue for this kind of endpoint.
 - Check Lock
     - GET wp/v2/{base}/{id}/lock
         - User ID
         - Acquired
         - Expires
 - Aquire/Takeover a Lock
     - POST wp/v2/{base}/{id}/lock
 - Update a lock
     - Heartbeat implementation rejects this if the lock’s user has
 changed.
     - PUT wp/v2/{base}/{id}/lock
         - WP_Error 409 if user ID of current lock !== current user
 - Release a lock
     - DELETE wp/v2/{base}/{id}/lock

 An alternate way to distinguish between updating a lock and acquiring a
 lock besides POST vs PUT would be to use a conditional header like If-
 None-Match and generate an eTag based off of the user ID acquiring the
 lock.

 So:
 GET /lock
         ETag: md5( locked_by_id )

 POST /lock

 POST /lock
 If-None-Match: “etag returned by the GET or acquiring a lock”

 An issue with it being a separate route is that a client would have to
 make an additional request to see if the locked state should be shown.
 This could be solved by adding an embeddable link to the lock endpoint to
 the post model.

 Concerns with this approach.
 - Not the most flexible. I could see us wanting multiple locks on a post
 at the same time for things like that collaborative edit mode that was
 prototyped.

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