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

WordPress Trac noreply at wordpress.org
Thu Oct 11 17:22:35 UTC 2018

#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

 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
     - 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

 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

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

More information about the wp-trac mailing list