HTTP как SQL

HTTP-запрос можно рассматривать как аналог SQL-оператора:

• GET /users — это Scan Users;
• GET /users/{{$.id}} — это Nested Loop.

Тогда исполнитель начинает работать как query planner / оптимизатор.

Оптимизатор меняет стратегию

Исполнитель знает возможности API и может менять стратегию исполнения, не трогая файл:

GET /users
  GET /orders/{{$.id}}

Наивно — users → foreach → orders. Но если исполнитель знает про /orders?userIds=..., он собирает ids и делает один bulk-запрос.

Файл не меняется. Меняется оптимизатор. Как в SQL.

Оптимизатор оценивает объём: 100 организаций → ~4000 HTTP-запросов — и предлагает варианты: bulk endpoint, выполнять по 10 одновременно.

Dataflow, а не workflow

Файл должен описывать поток данных, а не последовательность шагов. Не «сделай Login, потом Users, потом Orders», а:

• существует поток Organizations;
• из него получается поток Users;
• из него — Orders;
• из него — Payments.

Это мышление dataflow, близкое к Unix pipes, Apache Beam, DataFusion, LINQ и React: разработчик описывает преобразование данных, а не шаги.

.http как декларативный язык

Если идею довести до конца, .http перестаёт быть «файлом для тестирования API» и становится тем, чем SQL когда-то стал для баз данных — декларативным языком работы с распределёнными HTTP-ресурсами. SQL не говорит движку, как выполнять запрос — он говорит, что получить. Оптимизатор сам выбирает порядок соединений, индексы и стратегию.

Именно «HTTP как декларативный язык потоков данных с оптимизатором исполнения» отличает эту концепцию от n8n, LangGraph и традиционных .http-клиентов: это другая модель программирования интеграций, а не новый синтаксис.

Источники

• Обсуждение концепции httplan — диалог с ChatGPT (2026-07-08), chatgpt.com/share/6a4e7804-ce90-83ed-acd0-0def6540872d

Связанные заметки

• httplan — исполняемый HTTP-документ
• План исполнения как отдельная сущность
• Блоки вместо ключевых слов