Changes between Initial Version and Version 1 of Ticket #44862, comment 9
- Timestamp:
- 10/11/2018 05:36:44 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #44862, comment 9
initial v1 23 23 - DELETE wp/v2/{base}/{id}/lock 24 24 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.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-Match and generate an eTag based off of the user ID acquiring the lock. 26 26 27 27 So: … … 32 32 33 33 POST /lock 34 If- None-Match: “etag returned by the GET or acquiring a lock”34 If-Match: “etag returned by the GET or acquiring a lock” 35 35 36 36 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.