WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #44862, comment 9


Ignore:
Timestamp:
10/11/2018 05:36:44 PM (22 months ago)
Author:
TimothyBlynJacobs
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #44862, comment 9

    initial v1  
    2323    - DELETE wp/v2/{base}/{id}/lock
    2424
    25 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.
     25An 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-Match and generate an eTag based off of the user ID acquiring the lock.
    2626
    2727So:
     
    3232
    3333POST /lock
    34 If-None-Match: “etag returned by the GET or acquiring a lock”
     34If-Match: “etag returned by the GET or acquiring a lock”
    3535
    3636An 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.