Optimistic locks via HTTP Conditional Requests
Optimistic locking підхід може бути розроблений шляхом використання ETag http header approach.
Кожен RestAPI ресурс буде маркуватись контрольною сумою в ETag http_header в Response, що відправляється клієнту. Кожен PUT або DELETE запит буде маркуватись попередньо отриманим ETag та If-Match інструкцією. Сервер в такому випадку перевірятиме наявність ресурсу з відповідним ID, що той також має контрольну суму, що відповідає значенню в ETag, перед виконанням самої операції над сутністю. Якщо ресурс на момент оримання PUT або POST змінився, котнорльна сума не співпаде і така операція буде відхилена з 412 http status code.
Pros
-
Потребує лише часткової зміни RestAPI контракту (робота з додатковими http headers)
-
Використовується стандартизований підхід для забезпечення optimistic locking задокументований в RFC-2616: Hypertext Transfer Protocol — HTTP/1.1
-
Використання стандартизованого підходу дозволяє використовувати існуючі технічні інструменти для роботи з http conditional requests (для spring boot).
-
Optimistic locking відбувається на рівні запитів Rest Controllers, та не потребує додаткової обробки на рівні сервісів
| TODO: will be an issue in a case of service scaling? |
Cons
Якщо HTTP Request не буде мати ETag http header, то це дозволить йому змінити існуючий ресурс навіть, якщо він був уже кимось змінений раніше (відбудеться затирання одних змін іншими).
| Дана поведінка може бути змінена технічним шляхом, але це суперечитиме контракту використання ETag описаному в RFC. |
| Якщо клієнт буде використовувати у всіх PUT та DELETE запитах ETag то це забезпечить optimistic locking на рівні RestAPI. |