more fixes and clarifications to chapter 11

src/en/clean-copy/02-Section I. The API Design/05.md

@@ -172,7 +172,7 @@ We're leaving the exercise of making these signatures better to the reader.
 
 It's considered good form to use globally unique strings as entity identifiers, either semantic (i.e. "lungo" for beverage types) or random ones (i.e. [UUID-4](https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random))). It might turn out to be extremely useful if you need to merge data from several sources under single identifier.
 
-In general, we tend to advice using urn-like identifiers, e.g. `urn:order:<uuid>` (or just `order:<uuid>`). That helps a lot when dealing with legacy systems with different identifiers attached to the same entity. Namespaces in urns help to understand quickly which identifier is used, and is there a usage mistake.
+In general, we tend to advice using urn-like identifiers, e.g. `urn:order:<uuid>` (or just `order:<uuid>`). That helps a lot in dealing with legacy systems with different identifiers attached to the same entity. Namespaces in urns help to understand quickly which identifier is used, and is there a usage mistake.
 
 One important implication: **never use increasing numbers as external identifiers**. Apart from abovementioned reasons, it allows counting how many entities of each types there are in the system. You competitors will be able to calculate a precise number of orders you have each day, for example.
 
@@ -224,6 +224,11 @@ GET /v1/orders/{id}
 →
 { "order_id", "status" … }
 ```
+```
+// Returns all customers's orders
+// in all statuses
+GET /v1/users/{id}/orders
+```
 
 ##### Avoid double negations
 

src/ru/clean-copy/02-Раздел I. Проектирование API/05.md

@@ -219,6 +219,12 @@ GET /v1/orders/{id}
 →
 { "order_id", "status" … }
 ```
+```
+// Возвращает все заказы пользователя
+// во всех статусах
+GET /v1/users/{id}/orders
+```
+
 
 ##### Избегайте двойных отрицаний