Deploying to gh-pages from @ 6827579 🚀

httpstatuscodes/index.html

@@ -132,7 +132,7 @@
 для базового экземпляра
 для создания кэшированной сущности для конкретного экземпляра.</p><h3>Wikipedia</h3><p>Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.
 Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.</p></div></div></div><h2 class=mt-3><a data-bs-toggle=collapse href=#collapse3xx class="text-body-emphasis text-decoration-none">3xx:
-Redirect</a></h2><div id=collapse3xx class=collapse><p>Данный класс кодов состояния показывает, что дальнейшие действия должны быть выполнены клиентом для тоо,
+Redirect</a></h2><div id=collapse3xx class=collapse><p>Данный класс кодов состояния показывает, что дальнейшие действия должны быть выполнены клиентом для того,
 чтобы запрос завершился успешно.
 Требуемое действие может быть выполнено клиентом без участия пользователя тогда и только тогда, когда
 следующий запрос будет GET или HEAD.

lessons/httpmethods/index.html

@@ -17,7 +17,7 @@
 В случае „удачного” (или не содержащего ошибок) адреса,
 GET возвращается представление ресурса в формате XML или JSON в сочетании с кодом состояния HTTP 200 (OK).
 В случае наличия ошибок обычно возвращается код 404 (NOT FOUND) или 400 (BAD REQUEST).</p><p>В соответствии спецификации HTTP, GET (так же как и HEAD) запросы используются только для чтения данных,
-не изменя их.
+не изменяя их.
 Таким образом, при соблюдении данного соглашения, они считаются безопасными.
 То есть они могут использоваться без риска изменения данных, вне зависимости от того,
 один раз данные были получены, или же 10, или ни разу вовсе.
@@ -50,7 +50,7 @@
 рассмотрения)</p><p>Если PUT запрос используется для увеличения счётчика просмотра конкретного ресурса
 — данный запрос уже не считается идемпотентным.
 Иногда такое происходит и считается достаточным задокументировать тот факт, что вызов не идемпотентен.
-Однако строго рекомендуется выдерживать идемпотентность PUT запроса.</p><p><strong>Примеры:</strong></p><ul><li><em>PUT http://www.example.com/customers/12345</em></li><li><em>PUT http://www.example.com/customers/12345/orders/98765</em></li><li><em>PUT http://www.example.com/buckets/secret_stuff</em></li></ul></div><div class="tab-pane fade" id=patch role=tabpanel aria-labelledby=patch-tab><p>PATCH запрос используется для **модификации** ресурса. PATCH запрос должен содержать только изменяемые данные ресурса, а не все его данные.</p><p>Это напоминает работу PUT запроса, но в теле запроса содержится набор инструкций описывающих как должен быть изменён ресурс, расположенный на сервере, для формирования новой версии. Это означает, что тело PATCH запроса должно содержать не просто изменения ресурса, а представлять из себя описание на языке внесения изменений (patch language) таких как JSON Patch или XML Patch.</p><p>PATCH запрос ни является безопасным, ни идемпотентным. Однако PATСH запрос может быть сформирован таким образом чтобы быть идемпотентным, что в свою очередь помогает предотвратить негативные последствия от коллизий между двумя PATCH запросами к одному и тому же ресурсу в один и тот же промежуток времени. Коллизии нескольких PATCH запросов могут быть более опасными чем коллизии PUT запросов, потому что некоторым форматам изменеий необходимо выполняться от известной базовой-точки или ресурс будет поврежден. Клиенты, использующие такой тип внесения изменений, должны использовать условный запрос на проверку изменения ресурса с момента последнего доступа клиента к нему. Например клиент может использовать ETag в заголовке If-Match в самом PATСH запросе.</p><p><strong>Примеры:</strong></p><ul><li><em>PATCH http://www.example.com/customers/12345</em></li><li><em>PATCH http://www.example.com/customers/12345/orders/98765</em></li><li><em>PATCH http://www.example.com/buckets/secret_stuff</em></li></ul></div><div class="tab-pane fade" id=post role=tabpanel aria-labelledby=post-tab><p>POST запрос наиболее часто используется для создания новых ресурсов.
+Однако строго рекомендуется выдерживать идемпотентность PUT запроса.</p><p><strong>Примеры:</strong></p><ul><li><em>PUT http://www.example.com/customers/12345</em></li><li><em>PUT http://www.example.com/customers/12345/orders/98765</em></li><li><em>PUT http://www.example.com/buckets/secret_stuff</em></li></ul></div><div class="tab-pane fade" id=patch role=tabpanel aria-labelledby=patch-tab><p>PATCH запрос используется для **модификации** ресурса. PATCH запрос должен содержать только изменяемые данные ресурса, а не все его данные.</p><p>Это напоминает работу PUT запроса, но в теле запроса содержится набор инструкций описывающих как должен быть изменён ресурс, расположенный на сервере, для формирования новой версии. Это означает, что тело PATCH запроса должно содержать не просто изменения ресурса, а представлять из себя описание на языке внесения изменений (patch language) таких как JSON Patch или XML Patch.</p><p>PATCH запрос ни является безопасным, ни идемпотентным. Однако PATСH запрос может быть сформирован таким образом чтобы быть идемпотентным, что в свою очередь помогает предотвратить негативные последствия от коллизий между двумя PATCH запросами к одному и тому же ресурсу в один и тот же промежуток времени. Коллизии нескольких PATCH запросов могут быть более опасными чем коллизии PUT запросов, потому что некоторым форматам изменений необходимо выполняться от известной базовой-точки или ресурс будет поврежден. Клиенты, использующие такой тип внесения изменений, должны использовать условный запрос на проверку изменения ресурса с момента последнего доступа клиента к нему. Например клиент может использовать ETag в заголовке If-Match в самом PATСH запросе.</p><p><strong>Примеры:</strong></p><ul><li><em>PATCH http://www.example.com/customers/12345</em></li><li><em>PATCH http://www.example.com/customers/12345/orders/98765</em></li><li><em>PATCH http://www.example.com/buckets/secret_stuff</em></li></ul></div><div class="tab-pane fade" id=post role=tabpanel aria-labelledby=post-tab><p>POST запрос наиболее часто используется для создания новых ресурсов.
 На практике он используется для создания вложенных ресурсов.
 Другими словами, при создании нового ресурса, POST запрос отправляется к родительскому ресурсу и,
 таким образом, сервис берет на себя ответственность на установление связи создаваемого ресурса с