styling improved

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

@@ -292,7 +292,7 @@ GET /v1/orders/{id}
   2. Уровень программы исполнения. Для API первого типа он будет представлять собой просто обёртку над существующим API программ; для API второго типа концепцию «рантайма» программ придётся полностью имплементировать нам.
 
 Что это будет означать практически? Разработчик по-прежнему будет создавать заказ, оперируя только высокоуровневыми терминами:
-```
+```json
 POST /v1/orders
 {
   "coffee_machine_id",
@@ -304,14 +304,14 @@ POST /v1/orders
 ```
 
 Имплементация функции `POST /orders` проверит все параметры заказа, заблокирует его стоимость на карте пользователя, сформирует полный запрос на исполнение и обратится к уровню исполнения. Сначала необходимо подобрать правильную программу исполнения:
-```
+```json
 POST /v1/program-matcher
 { "recipe", "coffee-machine" }
 →
 { "program_id" }
 ```
 Получив идентификатор программы, нужно запустить её на исполнение:
-```
+```json
 POST /v1/programs/{id}/run
 {
   "order_id",
@@ -337,7 +337,7 @@ POST /v1/programs/{id}/run
 
 Уровень рантаймов API второго типа, исходя из общих соображений, будет скорее всего непубличным, и мы плюс-минус свободны в его имплементации. Самым простым решением будет реализовать виртуальную state-машину, которая создаёт «рантайм» (т.е. stateful контекст исполнения) для выполнения программы и следит за его состоянием.
 
-```
+```json
 POST /v1/runtimes
 {
   "coffee_machine", 
@@ -348,7 +348,7 @@ POST /v1/runtimes
 { "runtime_id", "state" }
 ```
 Здесь `program` будет выглядеть примерно так:
-```
+```json
 {
   "program_id",
   "api_type",
@@ -363,7 +363,7 @@ POST /v1/runtimes
 }
 ```
 А `state` вот так:
-```
+```json
 {
   // Статус рантайма
   // * "pending" — ожидание