diff --git a/API.ru.html b/API.ru.html
index c8b2952..06ed9d0 100644
--- a/API.ru.html
+++ b/API.ru.html
@@ -144,6 +144,33 @@
 
 <p>Если мы вернёмся к нашему примеру с погодным api, то увидим, что один уровень абстракции выделился автоматически: http api. Мы можем построить прочие виды api поверх базового http. Можем ли мы выделить ещё какие-то уровни, скажем, внутри самого http api?</p>
 
+<h4>Построение иерархии абстракций</h4>
+
+<p>Как обычно, мы начнём с вопроса "зачем" - если у нас не получается строгая иерархия, зачем нужна нестрогая? В первую очередь для того, чтобы вашим разработчикам было удобнее пользоваться вашим api. Представим, что мы спроектировали вот такой интерфейс для нашего http api:</p>
+
+<ul>
+<li>GET /weather/temperature/{city_id} - возвращает текущую температуру в городе с указанным идентификатором;</li>
+<li>GET /weather/temperature/{city_id}/forecast - возвращает прогноз изменения температуры;</li>
+<li>GET /weather/pressure/{city_id} - возвращает атмосферное давление.<li>
+</ul>
+
+<p>Покрывает ли такой интерфейс наши сценарии использования? С одной стороны кажется, что да - каждый потребитель сможет получить нужный ему набор информации.</p>
+
+<p>Но, с другой стороны, будет ли удобно вебмастеру, который хочет просто установить на свой сайт "прогноз погоды", пользоваться таким api? Понятно, что ему не нужны по отдельности ни температура, ни давление - ему нужна ровно та информация, которую захочет увидеть пользователь его ресурса.</p>
+
+<p>Оптимально было бы ввести ещё один метод:</p>
+<ul><li>GET /weather/{city_id} - возвращает параметры погоды в указанном городе: температуру, давление, прогноз.</li></ul>
+
+<p>Этот новый ресурс позволит пользователям api оперировать не в метеорологических терминах - а в терминах задачи, которую они решают. Тем самым мы спроектировали интерфейс высокого уровня, опирающийся на интерфейсы нижнего уровня абстракции.</p>
+
+<p>Аналогично, если мы будем проектировать api для новостных ресурсов, то придём к необходимости выделения сущности "картина атмосферных фронтов"; при проектировании api для диспетчерских служб - к сущности "план опасных для полета зон", и так далее.</p>
+
+<p>Разделение уровней абстракции должно происходить вдоль трёх направлений:</p>
+<ul><li>от сценариев использования к их внутренней реализации: высокоуровневые сущности и номенклатура их методов должны напрямую отражать сценарии использования api; низкоуровневый - отражать декомпозицию сценариев на составные части;</li>
+<li>от терминов предметной области пользователя к терминам предметной области исходных данных - в нашем случае от высокоуровневых понятий "прогноз погоды" и "движение атмосферных фронтов" к базовым "температура", "давление", "скорость ветра";</li>
+<li>наконец, от структур данных, в которых удобно оперировать пользователю к структурам данных, максимально приближенных к "сырым" - в нашем случае от "атмосферных фронтов" и "магнитных бурь" - к сырым байтовый данным, описывающим поле атмосферного давления или магнитное поле Земли.</li>
+
+</ul>
 
 <!--
     <h2>О проектировании API</h2>