Является ли RESTful протоколом?

Является ли REST архитектурным стилем или протоколом?

REST (Representational State Transfer) — это не протокол, а архитектурный стиль (архитектурный подход или набор принципов) для построения распределенных систем, в частности веб-сервисов. Это принципиально важное различие, которое часто становится причиной путаницы. REST определяет правила, ограничения и рекомендации по проектированию, а не низкоуровневые детали обмена сообщениями, такие как форматы фреймов или коды ошибок, что характерно для протоколов (например, HTTP, FTP, SMTP).

Ключевые отличия архитектурного стиля от протокола

• Протокол — это строгий, формализованный стандарт, задающий как происходит коммуникация: синтаксис сообщений, последовательность действий, коды состояния, управление сессиями. Примеры: HTTP/1.1, WebSocket, TCP/IP. Их спецификации часто описываются в RFC-документах.
• Архитектурный стиль (REST) — это абстракция более высокого уровня, описывающая какие принципы должны быть применены к системе, чтобы она обладала определенными свойствами (масштабируемостью, надежностью, простотой). Он использует существующие протоколы (прежде всего HTTP) как транспорт.

Как REST соотносится с HTTP?

REST чаще всего реализуется поверх протокола HTTP, но теоретически может использовать и другие протоколы. HTTP предоставляет идеальную основу для воплощения принципов REST благодаря своим методам, статусам и stateless-природе. Когда говорят о "RESTful API", почти всегда подразумевают веб-сервис, построенный по принципам REST и использующий HTTP.

REST задает "что делать", а HTTP — "как это сделать технически".

Основные принципы (ограничения) REST по Роя Филдингу

Эти принципы подтверждают, что REST — это стиль проектирования, а не протокол:

1. Единообразие интерфейса (Uniform Interface): Унифицированный способ взаимодействия с ресурсами через URI, HTTP-методы, представления (JSON/XML) и гипермедиа (ссылки).
2. Отсутствие состояния (Stateless): Каждый запрос от клиента к серверу должен содержать всю необходимую информацию для его обработки. Сервер не хранит состояние сессии клиента между запросами.
3. Кэшируемость (Cacheable): Ответы сервера должны явно или неявно определять, можно ли их кэшировать, чтобы повысить производительность.
4. Клиент-серверная архитектура: Четкое разделение ответственности: клиент занимается UI и состоянием приложения, сервер — обработкой данных и хранением.
5. Слои (Layered System): Архитектура может состоять из нескольких слоев (прокси, балансировщики, шлюзы), что скрыто от клиента и обеспечивает масштабируемость.
6. Код по требованию (Code on Demand, опционально): Сервер может расширять функциональность клиента, передавая исполняемый код (например, JavaScript).

Пример RESTful-подхода в коде (использование HTTP как протокола)

Вот как принципы REST реализуются через HTTP-протокол в PHP:

// Пример RESTful эндпоинта для ресурса "Статьи"
// GET /api/articles - получение списка статей (применение HTTP метода GET)
if ($_SERVER['REQUEST_METHOD'] === 'GET' && $_SERVER['REQUEST_URI'] === '/api/articles') {
    header('Content-Type: application/json');
    http_response_code(200); // Использование HTTP кода состояния
    echo json_encode(['articles' => [['id' => 1, 'title' => 'О REST']]]); // Передача представления в JSON
}

// POST /api/articles - создание новой статьи (HTTP метод POST для создания)
if ($_SERVER['REQUEST_METHOD'] === 'POST' && $_SERVER['REQUEST_URI'] === '/api/articles') {
    $inputData = json_decode(file_get_contents('php://input'), true);
    // ... сохранение статьи ...
    header('Content-Type: application/json');
    http_response_code(201); // HTTP статус 201 Created
    echo json_encode(['message' => 'Статья создана', 'id' => 123]);
}

// GET /api/articles/123 - получение конкретной статьи по ID (URI как идентификатор ресурса)
if (preg_match('/^\/api\/articles\/(\d+)$/', $_SERVER['REQUEST_URI'], $matches) && $_SERVER['REQUEST_METHOD'] === 'GET') {
    $articleId = $matches[1];
    // ... получение статьи $articleId из БД ...
    http_response_code(200);
    echo json_encode(['article' => ['id' => $articleId, 'title' => 'Конкретная статья']]);
}

Почему важно понимать эту разницу?

На практике многие API, называющие себя "RESTful", на самом деле являются RPC (Remote Procedure Call)-подобными API над HTTP, нарушая ключевые принципы REST (например, не используют гипермедиа, используют глаголы в URL, игнорируют кэширование). Понимание, что REST — это архитектурная дисциплина, а не синоним "JSON API над HTTP", позволяет проектировать более масштабируемые, понятные и долгоживущие системы.

Итог: REST — это архитектурный стиль и набор ограничений, которые применяются к проектированию распределенных систем. Для своей реализации он использует существующие протоколы, в 99.9% случаев — HTTP, который и является тем самым протоколом, управляющим непосредственно обменом данными в сети.