From 95215afb09ca598925edfd48fb413790f865512c Mon Sep 17 00:00:00 2001
From: Sergey Konstantinov <yatwirl@gmail.com>
Date: Sat, 11 Oct 2025 21:59:53 +0300
Subject: [PATCH] better wording

---
 .../10-api-patterns-partial-updates.md                        | 2 +-
 .../10-api-patterns-partial-updates.md                        | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/en/clean-copy/03-Section II. The API Patterns/10-api-patterns-partial-updates.md b/src/en/clean-copy/03-Section II. The API Patterns/10-api-patterns-partial-updates.md
index b4e1611..0ed4d24 100644
--- a/src/en/clean-copy/03-Section II. The API Patterns/10-api-patterns-partial-updates.md	
+++ b/src/en/clean-copy/03-Section II. The API Patterns/10-api-patterns-partial-updates.md	
@@ -230,4 +230,4 @@ X-Idempotency-Token: <token>
 
 This approach is much more complex to implement, but it is the only viable technique for realizing collaborative editing as it explicitly reflects the exact actions the client applied to an entity. Having the changes in this format also allows for organizing offline editing with accumulating changes on the client side for the server to resolve the conflict later based on the revision history.
 
-**NB**: One approach to this task is developing a set of operations in which the state of the system remains consistent regardless of the order in which the operations are applied. One example of such a nomenclature is a conflict-free replicated data type (*CRDT*).[ref Conflict-Free Replicated Data Type|ref:shapiro-et-al-crdt Conflict-Free Replicated Data Types](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) However, we consider this approach viable only in some subject areas, as in real life, the order of operation *is* typically important. If one user entered new text in the document and another user removed the document completely, there is no way to automatically resolve this conflict that would satisfy both users. The only correct way of resolving this conflict is explicitly asking users which option for mitigating the issue they prefer.
\ No newline at end of file
+**NB**: One approach to this task is developing a set of operations in which the state of the system remains consistent regardless of the order in which the operations are applied. One example of such a nomenclature is Conflict-Free Replicated Data Type (*CRDT*).[ref Conflict-Free Replicated Data Type|ref:shapiro-et-al-crdt Conflict-Free Replicated Data Types](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) However, we consider this approach viable only in some subject areas, as in real life, the order of operation *is* typically important. If one user entered new text in the document and another user removed the document completely, there is no way to automatically resolve this conflict that would satisfy both users. The only correct way of resolving this conflict is explicitly asking users which option for mitigating the issue they prefer.
\ No newline at end of file
diff --git a/src/ru/clean-copy/03-Раздел II. Паттерны дизайна API/10-api-patterns-partial-updates.md b/src/ru/clean-copy/03-Раздел II. Паттерны дизайна API/10-api-patterns-partial-updates.md
index f3491f2..8dace1f 100644
--- a/src/ru/clean-copy/03-Раздел II. Паттерны дизайна API/10-api-patterns-partial-updates.md	
+++ b/src/ru/clean-copy/03-Раздел II. Паттерны дизайна API/10-api-patterns-partial-updates.md	
@@ -130,7 +130,7 @@ PATCH /v1/orders/{id}↵
 
 При этом формат перестаёт быть простым и интуитивно понятным, что с нашей точки зрения делает такое улучшение спорным.
 
-**Более консистентное решение**: разделить эндпойнт на несколько идемпотентных суб-эндпойнтов, имеющих независимые идентификаторы и/или адреса (чего обычно достаточно для обеспечения независимости реузльтата от порядка операций). Этот подход также хорошо согласуется с принципом декомпозиции, который мы рассматривали в предыдущем главе [«Разграничение областей ответственности»](#api-design-isolating-responsibility).
+**Более консистентное решение**: разделить эндпойнт на несколько идемпотентных суб-эндпойнтов, имеющих независимые идентификаторы и/или адреса (чего обычно достаточно для обеспечения независимости результата от порядка выполнения операций). Этот подход также хорошо согласуется с принципом декомпозиции, который мы рассматривали в предыдущем главе [«Разграничение областей ответственности»](#api-design-isolating-responsibility).
 
 ```json
 // Создаёт заказ из двух напитков
@@ -187,7 +187,7 @@ PUT /v1/orders/{id}/items/{item_id}
 DELETE /v1/orders/{id}/items/{item_id}
 ```
 
-Теперь для удаления `volume` достаточно *не* передавать его в `PUT items/{item_id}`. Кроме того, обратите внимание, что результат выполнения операций удаления одного напитка и модификации другого теперь не зависит от порядка.
+Теперь для удаления `volume` достаточно *не* передавать его в `PUT items/{item_id}`. Кроме того, обратите внимание, что результат выполнения операций удаления одного напитка и модификации другого теперь не зависит от порядка применения.
 
 Этот подход также позволяет отделить неизменяемые и вычисляемые поля (`created_at` и `status`) от изменяемых, не создавая двусмысленных ситуаций (что произойдёт, если клиент попытается изменить `created_at`?).