Проверяет понимание того, что HTTP — это транспортный протокол, поверх которого можно реализовать любой прикладной протокол, включая GraphQL и JSON-RPC.
HTTP — это протокол прикладного уровня, который описывает, как клиент и сервер обмениваются сообщениями: метод, путь, заголовки, тело, статус ответа. Он не диктует, что именно должно лежать в теле запроса. Именно поэтому поверх HTTP можно реализовать любой другой протокол: REST, GraphQL, JSON-RPC, gRPC-Web и другие. HTTP выступает транспортом, а прикладной протокол определяет семантику данных.
GraphQL почти всегда использует HTTP: клиент отправляет POST-запрос на один эндпоинт (например, /graphql), в теле передаётся query, variables и operationName. Сервер возвращает JSON с полями data и errors. JSON-RPC тоже использует HTTP: обычно POST на один URL, тело содержит jsonrpc, method, params и id. Ответ содержит result или error и тот же id.
// GraphQL запрос через HTTP POST
POST /graphql
Content-Type: application/json
{
"query": "query { user(id: 1) { name } }",
"variables": {}
}
// JSON-RPC запрос через HTTP POST
POST /rpc
Content-Type: application/json
{
"jsonrpc": "2.0",
"method": "user.get",
"params": { "id": 1 },
"id": 1
}GraphQL и JSON-RPC не используют всю семантику HTTP: например, кэширование по URL плохо работает, потому что всё идёт на один эндпоинт. REST-подход с ресурсами и методами GET/PUT/DELETE здесь не применяется. Также важно правильно выбирать статусы: GraphQL часто возвращает 200 даже при ошибках в data.errors, что иногда усложняет мониторинг.
Итог: HTTP — универсальный транспорт, и строить поверх него GraphQL или JSON-RPC не только можно, но и стандартно. Это удобно, когда нужна гибкая выборка данных (GraphQL) или простой вызов методов (JSON-RPC) с использованием всей инфраструктуры HTTP.