diff --git a/src/ru/clean-copy/05-[В разработке] Раздел IV. HTTP API и REST/04.md b/src/ru/clean-copy/05-[В разработке] Раздел IV. HTTP API и REST/04.md
index 1412b21..e4ac4eb 100644
--- a/src/ru/clean-copy/05-[В разработке] Раздел IV. HTTP API и REST/04.md	
+++ b/src/ru/clean-copy/05-[В разработке] Раздел IV. HTTP API и REST/04.md	
@@ -40,7 +40,7 @@ HTTP/1.1 200 OK
 
 Конечно, большинство этих инструментов применимы и для работы с API, реализующими альтернативные парадигмы. Однако именно способность промежуточных агентов считывать метаданные HTTP запросов позволяет легко строить сложные конвейеры типа экспортировать access-логи nginx в Prometheus и из коробки получить удобные мониторинги статус-кодов ответов в Grafana.
 
-Отдельно заметим что HTTP API является на сегодняшний день выбором по умолчанию при разработке публичных API. В силу озвученных выше причин, как бы ни был устроен технологический стек партнёра, интегрироваться с HTTP API он сможет без особых усилий. При этом распространённость технологии понижает и порог входа, и требования к квалификации инженеров партёра.
+Отдельно заметим что HTTP API является на сегодняшний день выбором по умолчанию при разработке публичных API. В силу озвученных выше причин, как бы ни был устроен технологический стек партнёра, интегрироваться с HTTP API он сможет без особых усилий. При этом распространённость технологии понижает и порог входа, и требования к квалификации инженеров партнёра.
 
 Главным недостатком HTTP API является то, что промежуточные агенты, от клиентских фреймворков до API-гейтвеев, умеют читать метаданные запроса и выполнять какие-то действия с их использованием — настраивать политику перезапросов и таймауты, логировать, кэшировать, шардировать, проксировать и так далее — даже если вы их об этом не просили. Более того, так как стандарты HTTP являются сложными, концепция REST — непонятной, а разработчики программного обеспечения — неидеальными, то промежуточные агенты (и разработчики партнёра!) могут трактовать метаданные запроса *неправильно*. Особенно это касается каких-то экзотических и сложных в имплементации стандартов. Как правило, одной из причин разработки новых RPC-фреймворков декларируется стремление обеспечить простоту и консистентность работы с протоколом, чтобы таким образом уменьшить поле для потенциальных ошибок в реализации интеграции с API.
 
@@ -83,4 +83,4 @@ HTTP/1.1 200 OK
 В случае же разработки API менее общего назначения, мы рекомендуем подходить к выбору формата по тому же принципу:
   * взвесить накладные расходы на подготовку и внедрение инструментов чтения бинарных форматов и расшифровки бинарных протоколов против накладных расходов на неоптимальную передачу данных;
   * оценить, хватит ли вам качественного, но ограниченного в возможностях набора программного обеспечения, идущего в комплекте с альтернативным форматом, или вам важнее возможность использовать широкий спектр инструментов, умеющих работать с HTTP API, пусть они и не всегда высокого качества;
-  * прикинуть, насколько дорого вам обойдутся разработчики, способные работать с этим форматом.
\ No newline at end of file
+  * прикинуть, насколько дорого вам обойдутся разработчики, способные работать с этим форматом.