Каждый раз, когда вы синхронизируете CRM, запрашиваете обновления по доставке или связываете два SaaS-инструмента, всю тяжёлую работу за кулисами делает REST API. Большинство людей об этом даже не задумываются — пока что-то не сломается.
Вот что интересно: даже среди разработчиков нет единого понимания, что именно делает API «RESTful». Этот термин используют настолько вольно, что в одной ветке Reddit это сформулировали предельно честно: «Не думаю, что я когда-либо создавал хоть один по-настоящему RESTful API по определению Роя Филдинга». И это говорит разработчик, а не бизнес-пользователь. Концепция появилась в докторской диссертации Роя Филдинга 2000 года в UC Irvine, где REST описывался как архитектурный стиль — набор ограничений проектирования, а не протокол, не продукт и не спецификация, которую можно скачать. При этом, согласно отчёту Postman о состоянии API за 2025 год, REST используют 93% специалистов по API. То есть почти все им пользуются, но удивительно много команд при этом неверно понимают, что он на самом деле требует. В этой статье мы простым языком разберём 6 ключевых характеристик REST API, покажем, какие из них команды чаще всего реализуют неправильно, познакомим вас с моделью зрелости для самооценки и сравним REST с альтернативами — SOAP, GraphQL и gRPC.
Что такое REST API? (Простое определение)
REST (Representational State Transfer) — это набор правил проектирования того, как программные системы должны общаться по сети.
Если точнее, это архитектурный стиль, который задаёт ограничения — такие как безсостояность, кэшируемость и единый интерфейс, — определяющие, как клиенты (ваш браузер, мобильное приложение или инструмент автоматизации) взаимодействуют с серверами (где хранятся данные). Обычно REST работает поверх HTTP и чаще всего возвращает JSON, но сам REST не привязан ни к какому конкретному протоколу или формату данных.
Представьте, что это правила поведения за ужином. REST не диктует, какие блюда подавать и на каком языке разговаривать — он определяет, как передавать блюда, как попросить добавку и как показать, что вы закончили. Две системы, соблюдающие один и тот же этикет, могут общаться предсказуемо, даже если раньше никогда не встречались.
Чем REST НЕ является: REST — это не продукт, который вы устанавливаете. Это не протокол вроде HTTP или SOAP. И если API называют «RESTful», это ещё не значит, что он полностью соответствует исходным ограничениям Филдинга — чаще всего это лишь означает, что API использует URL ресурсов и HTTP-методы. Разрыв между «REST-подобным» и «по-настоящему RESTful» — один из главных источников путаницы в индустрии, и ниже мы разберём это подробнее.
6 характеристик REST API в одном взгляде
Прежде чем углубляться, вот краткая шпаргалка. Филдинг выделил 6 ограничений, которым API должен следовать, чтобы считаться RESTful. Пять из них обязательны, одно — опционально.
| Ограничение | Основная идея | Главная польза | Конкретный пример |
|---|---|---|---|
| Клиент-сервер | Разделить интерфейс и хранение данных | Фронтенд и бэкенд развиваются независимо | React SPA, обращающееся к REST API |
| Безсостояность | Каждый запрос несёт весь необходимый контекст | Горизонтальное масштабирование без привязки к сессии | Токен аутентификации в каждом заголовке запроса |
| Кэшируемость | Ответы явно указывают, можно ли их кэшировать | Меньше задержка и нагрузка на сервер | Cache-Control: max-age=3600 в ответе на GET |
| Единый интерфейс | Стандартизированное взаимодействие с ресурсами | Предсказуемая, легко изучаемая поверхность API | GET /users/42, DELETE /users/42 |
| Слоистая система | Клиент не знает, обращается ли он напрямую к серверу | Позволяет вставлять CDN, шлюз, балансировщик нагрузки | Client → CDN → API Gateway → App Server |
| Code-on-Demand (опционально) | Сервер может отправлять исполняемый код для расширения клиента | Расширение возможностей клиента по требованию | API возвращает фрагмент JavaScript-виджета |
Чтобы наглядно показать, как эти ограничения работают вместе в реальной системе, представьте такую слоистую архитектуру:
Клиент / Мобильное приложение
↓
CDN / Edge Cache (например, Cloudflare)
↓
API Gateway (ограничение скорости, auth, CORS)
↓
Балансировщик нагрузки
↓
Серверы приложений
↓
База данных / внутренние сервисы
Клиент обращается только к слою CDN. Он не знает, сколько уровней находится позади. Именно так и работает ограничение слоистой системы — а ещё так реализуются безопасность, кэширование и масштабирование, не требуя от клиента ничего об этом знать.
А теперь — подробный разбор.
Характеристики REST API: разбираем по одной
Разделение клиент-сервер
Первое ограничение Филдинга: клиент (то, с чем взаимодействуют пользователи) и сервер (где хранятся данные и выполняется логика) должны быть разделены. Он называл это разделением ответственности.
Почему это важно на практике? Потому что это означает, что мобильное банковское приложение может полностью изменить визуальный дизайн, не трогая базу счетов или механизм транзакций банка. Например, Salesforce Marketing Cloud REST API предоставляет доступ к контактам, кампаниям, journeys и push-уведомлениям через ресурсные конечные точки. Неважно, строите ли вы кастомную панель, мобильное приложение или подключаете сторонний инструмент — бэкенд остаётся тем же.
Для бизнес-команд это означает более быстрые итерации. Вашим дизайнерам фронтенда и инженерам бэкенда не нужно жить в одном релизном цикле. Пока контракт API стабилен, обе стороны могут двигаться независимо.
Безсостояность
Никакой памяти между запросами. Каждый вызов от клиента к серверу должен содержать всю информацию, необходимую серверу для обработки — сервер не сохраняет ничего из предыдущих взаимодействий.
Я люблю сравнивать это со звонком в службу поддержки, где каждый раз приходится заново объяснять свою проблему. Раздражает? Да, конечно. Но плюс огромный: помочь вам может любой свободный оператор, а колл-центр может добавить ещё 500 операторов без переделки всей системы. Это и есть горизонтальное масштабирование.
С технической точки зрения безсостояность означает отсутствие sticky sessions. Балансировщик нагрузки может направить ваш следующий запрос на любой исправный сервер. Если один сервер упадёт, другой подхватит запрос без потери ритма. В диссертации Филдинга прямо отмечается, что безсостояность улучшает наблюдаемость (инструменты мониторинга могут понимать каждый запрос отдельно), надёжность (сбои не повреждают общее состояние сессии) и масштабируемость (серверы могут освобождать ресурсы между запросами).
Практическая оговорка: в реальных системах всё же существуют токены аутентификации, корзины покупок и OAuth-потоки. Смысл не в том, что вообще нигде не должно быть состояния — смысл в том, что сервер не хранит состояние сессии клиента в своей памяти между запросами. Вместо этого это берут на себя токены, базы данных и общие кэши.
Кэшируемость
Можно ли переиспользовать этот ответ? Именно на этот вопрос отвечает кэшируемость. Ответы должны явно указывать, можно ли их кэшировать, и если да, клиенты и посредники (например, CDN) переиспользуют их для эквивалентных будущих запросов — снижая нагрузку на сервер и ускоряя работу.
Механизм HTTP довольно прост: заголовки вроде Cache-Control, ETag, Last-Modified и Expires говорят кэшам, как долго ответ считается действительным и когда нужно перепроверить его заново. Для бизнес-читателя это можно представить как пометку на ответе: «этот ответ актуален в течение следующего часа» или «каждый раз запрашивай свежую версию».
Влияние на производительность вполне реальное. В тестах Cloudflare Regional Tiered Cache сообщалось об улучшении времени ответа при попадании в хвостовой кэш на 50–100 мс. А в самой диссертации Филдинга показано, как веб-трафик вырос со 100 000 запросов в день в 1994 году до 600 000 000 запросов в день в 1999 году — и кэширование было одним из ключевых факторов такого роста.
Обычно кэшируются: каталоги товаров, публичный контент блога, списки стран/валют, документация API.
Обычно не кэшируются: личные панели, итоги оформления заказа, балансы счетов, административные отчёты.
Единый интерфейс
Это то ограничение, которое сам Филдинг называл центральной особенностью, отличающей REST от других архитектурных стилей. Оно стандартизирует взаимодействие клиентов с ресурсами, делая API предсказуемым.
Под этим общим правилом скрываются четыре подпункта:
- Идентификация ресурсов: у каждого ресурса есть стабильный URI.
/customers/123— это клиент./orders/456— это заказ. - Манипулирование через представления: клиенты работают с представлениями ресурсов (JSON, XML, HTML), а не с внутренними объектами сервера.
- Самоописательные сообщения: запросы и ответы содержат достаточно метаданных — метод, код статуса, тип контента, детали ошибки, — чтобы их мог понять любой посредник или клиент.
- HATEOAS (Hypermedia as the Engine of Application State): ответы включают ссылки на связанные действия и ресурсы, чтобы клиент мог понять, что делать дальше, без жёсткой прошивки каждого конечного адреса.
Соответствие HTTP-методов — самая заметная часть единого интерфейса:
| HTTP-метод | Значение в CRUD | Безопасен? | Идемпотентен? | Пример |
|---|---|---|---|---|
| GET | Чтение | Да | Да | GET /products/42 |
| POST | Создание / действие | Нет | Нет | POST /orders |
| PUT | Полная замена ресурса | Нет | Да | PUT /users/42 |
| PATCH | Частичное обновление | Нет | Не гарантируется | PATCH /users/42 |
| DELETE | Удаление | Нет | Да | DELETE /sessions/abc |
Руководства Google Cloud по HTTP прямо указывают, что GET должен быть безопасным, а GET, PUT и DELETE — идемпотентными. Известные API от GitHub, Stripe и Spotify довольно строго следуют этим шаблонам, поэтому разработчики, освоив один из них, быстро осваивают и другие.
Слоистая система
Ваш клиент не знает, общается ли он с исходным сервером, кэшем CDN, API-шлюзом или балансировщиком нагрузки. В этом и смысл — каждый компонент видит только соседний слой.
Именно это позволяет:
- CDN вроде Cloudflare стоять перед вашим API и кэшировать, а также ускорять ответы
- API-шлюзам (AWS API Gateway, Kong, Apigee) заниматься аутентификацией, ограничением скорости и квотами
- Балансировщикам нагрузки распределять безсостояние запросы между несколькими серверами приложений
В отчёте Postman за 2025 год отмечается, что 47% организаций используют AWS API Gateway, 26% — шлюз Azure, а 31% — несколько шлюзов одновременно. Слоистая архитектура — это не теория, а то, как реально устроены production-системы.
Компромисс в том, что каждый слой добавляет небольшую задержку. Но Филдинг утверждал, что общее кэширование на промежуточных уровнях в большинстве реальных систем с лихвой компенсирует эти издержки.
Code-on-Demand (опционально)
Это особый случай. Code-on-Demand — единственное необязательное ограничение REST: сервер может отправлять исполняемый код, например JavaScript, чтобы расширять функциональность клиента на лету.
Самый распространённый пример в реальном мире — это обычная веб-страница, загружающая JavaScript с сервера. Но для типичных JSON REST API, которые используют мобильные приложения, backend jobs или инструменты автоматизации, code-on-demand почти никогда не применяется. Клиентские приложения обычно не хотят выполнять произвольный код с удалённого сервера.
Для большинства читателей это ограничение — скорее примечание. Оно есть в модели Филдинга для полноты, но в повседневной оценке API почти не играет роли.
Что большинство понимает неправильно: действительно ли большинство REST API — это RESTful?
Вот часть, о которой не любят говорить: большинство production API, называющих себя «RESTful», на деле — это HTTP JSON API с REST-подобными соглашениями. Они используют URL ресурсов, HTTP-методы и коды статуса — и на этом всё. В ветке Reddit в r/softwarearchitecture разработчики признавались, что никогда не создавали по-настоящему REST API, соответствующий Филдингу. Другая дискуссия в r/learnprogramming свелась к спорам о том, может ли вообще кто-то прийти к общему мнению относительно того, что значит «RESTful».
Исследование 2026 года, в рамках которого интервьюировали 16 экспертов по REST API, показало, что, хотя рекомендации повышают удобство, разработчики заметно сопротивляются жёстким REST-правилам, ссылаясь на объём требований и слабое соответствие специфике своей организации.
Так где же эти ограничения реально применяются на практике?
| Ограничение | Реальное внедрение | Почему |
|---|---|---|---|
| Клиент-сервер | ✅ Почти везде | Базовый принцип веб-архитектуры; его трудно избежать |
| Безсостояность | ✅ Почти везде | Необходима для горизонтального масштабирования; стандартная практика |
| Единый интерфейс (базовый) | ✅ Часто | URI ресурсов + HTTP-глаголы — шаблон по умолчанию |
| Кэшируемость | ⚠️ Непоследовательно | Многие команды вообще не добавляют заголовки Cache-Control |
| Слоистая система | ⚠️ Неявно | CDN и шлюзы есть, но их не всегда проектируют осознанно |
| HATEOAS | ❌ Редко | Клиенты чаще хардкодят конечные точки; обнаружение через ссылки усложняет систему |
| Code-on-Demand | ❌ Очень редко | По определению опционально; почти никогда не реализуется в JSON API |
Почему команды пропускают HATEOAS: разработчики клиентской части предпочитают читать документацию OpenAPI и использовать SDK, а не динамически следовать по ссылкам во время выполнения. HATEOAS требует стабильных типов медиа, определений связей между ссылками и моделирования рабочих процессов — краткосрочные затраты высоки, а польза для большинства команд неочевидна.
Практический вывод: API не обязан быть на 100% совместимым с Филдингом, чтобы быть полезным. Но понимание того, какие ограничения вы пропустили и что вы теряете из-за этого, помогает принимать более удачные архитектурные и интеграционные решения.
Модель зрелости Ричардсона: насколько ваш API RESTful на самом деле?
Если бинарный вопрос «RESTful он или нет?» кажется бесполезным, модель зрелости Ричардсона даёт более практичную рамку. Предложенная Леонардом Ричардсоном и объяснённая Мартином Фаулером, она делит внедрение REST на четыре уровня.
| Уровень | Название | Описание | Пример из реальной жизни |
|---|---|---|---|
| 0 | Болото POX | Один URI, один HTTP-метод (обычно POST) | Устаревшие SOAP-over-HTTP конечные точки; POST /api с { "action": "getUser" } |
| 1 | Ресурсы | Несколько URI (по одному на ресурс), но по-прежнему в основном POST | POST /users/123/getProfile, POST /orders/456/cancel |
| 2 | HTTP-глаголы | Корректное использование GET, POST, PUT, DELETE + правильные коды статуса | Большинство production «REST» API сегодня |
| 3 | Гипермедиа (HATEOAS) | Ответы включают ссылки на связанные действия/ресурсы | Spring Data REST, API на базе HAL; на практике — очень мало публичных API |
Большинство API, с которыми вы столкнётесь, находятся на уровне 2. Они правильно используют ресурсы, глаголы и коды статуса. Этого достаточно, чтобы они были практичными, совместимыми и хорошо поддерживаемыми. Уровень 3 — это полное видение Филдинга, но распространён он пока слабо.
На каком уровне находится ваш API? Спросите себя:
- Есть ли у API одна конечная точка для всего? (Уровень 0)
- Есть ли у каждого бизнес-объекта свой URI? (Уровень 1+)
- Правильно ли используются HTTP-методы и коды статуса? (Уровень 2)
- Подсказывают ли ответы клиенту, что он может сделать дальше, не опираясь на внешнюю документацию? (Уровень 3)
Эта модель — самый полезный инструмент, который я знаю, чтобы выйти из спора «это REST или нет». Она заменяет бинарную оценку спектром.
Распространённые ошибки REST API и как их избежать
Я достаточно много интегрировал сторонние API, чтобы собрать собственный список раздражающих проблем. И судя по форумам разработчиков, я не одинок. Вот анти-паттерны, которые встречаются чаще всего, — и каждый из них напрямую нарушает одно из REST-ограничений.
| Анти-паттерн | Почему это ломает REST | Что делать вместо этого |
|---|---|---|---|
| HTTP 200 с телом ошибки ({ "error": "Invalid username" }) | Нарушает самоописательные сообщения; клиент не может доверять коду статуса | Используйте подходящие коды 4xx/5xx + структурированное тело ошибки (например, application/problem+json) |
| POST для всего | Игнорирует единый интерфейс; теряются безопасные/идемпотентные семантики | Соотносите CRUD с GET/POST/PUT(PATCH)/DELETE |
| Нет заголовков Cache-Control | Полностью обнуляет пользу кэшируемости | Указывайте явные директивы кэша — даже no-store для чувствительных данных |
| Размытые ошибки («409 error») | Люди и машины не могут понять, что пошло не так | Указывайте тип ошибки, понятное сообщение и ссылку на документацию |
| Нет HTTPS | Bearer-токены и API-ключи передаются в открытом виде | Включите TLS везде; Google APIs по умолчанию работают только по HTTPS |
| Версионирование в теле запроса | Нарушает идентификацию ресурса; шлюзы и кэши не могут корректно маршрутизировать запросы | Используйте версионирование в URI-пути (/v1/) или через заголовок Accept |
Рекомендации Zalando по RESTful API требуют официальные коды HTTP-статуса и советуют использовать Problem JSON для ответов с ошибками. Рекомендации Adidas по API уточняют, что Problem Detail следует использовать только для 4xx/5xx и никогда не смешивать с 2xx. Это не академические предпочтения — это production-стандарты команд, которые эксплуатируют API в больших масштабах.
В одной ветке Reddit в r/learnprogramming разработчик всерьёз спрашивал, нормально ли всегда возвращать HTTP 200 при ошибках. Сам факт, что этот вопрос всё ещё возникает в 2026 году, говорит о том, насколько живучи эти анти-паттерны.
REST vs SOAP vs GraphQL vs gRPC: сравнение характеристик REST API
Понимать REST в отрыве от всего — полезно. Понимать его в сравнении с альтернативами — ещё лучше.
| Измерение | REST | SOAP | GraphQL | gRPC |
|---|---|---|---|---|
| Протокол / транспорт | Архитектурный стиль, обычно HTTP | XML-based messaging protocol; HTTP, SMTP и т. д. | Язык запросов / runtime, обычно поверх HTTP | RPC framework over HTTP/2 |
| Формат данных | Обычно JSON, также XML/HTML | Только XML (контракты WSDL) | JSON, совпадающий с формой запроса | Protocol Buffers (бинарный) |
| Кэширование | ✅ Нативный HTTP-кэш при правильном проектировании | ❌ Сложно; плохо совместимо с HTTP-кэшем | ⚠️ Сложнее (POST + одна конечная точка + вариативность запросов) | ❌ Не ориентирован на HTTP-кэш |
| Поддержка real-time | ❌ Polling/webhooks | ❌ Enterprise messaging patterns | ✅ Подписки | ✅ Потоковая передача, низкая задержка |
| Кривая обучения | Низкая–средняя | Высокая | Средняя | Средняя–высокая |
| Лучше всего подходит для | Публичных API, CRUD, веб- и мобильных интеграций | Enterprise/legacy, жёстких контрактов, compliance | Сложных запросов, гибких фронтендов, мобильных приложений | Межсервисного взаимодействия, внутренних систем с высокой производительностью |
Сравнение архитектурных стилей API от Postman рекомендует выбирать решение на основе совместимости, формы данных, операций и инструментов для пользователей.
Когда что выбирать:
- REST выигрывает, когда нужна широкая совместимость, простые CRUD-операции и HTTP-кэширование. Это стандарт по умолчанию для публичных API и веб-/мобильных интеграций.
- SOAP по-прежнему уместен в enterprise-системах со строгими контрактами, требованиями WS-Security или наследуемыми интеграциями, которые никуда не исчезнут.
- GraphQL особенно хорош, когда фронтенду нужны гибкие вложенные запросы и вы хотите избежать избыточной или недостаточной выборки данных — это часто встречается в сложных мобильных приложениях.
- gRPC создан для внутренней межсервисной коммуникации, где низкая задержка и бинарная сериализация важнее совместимости с браузером.
В качестве реального REST-примера: Thunderbit Open API использует простые POST-конечные точки (/distill и /extract), JSON в запросах и ответах, аутентификацию по bearer-токену и стандартные HTTP-коды статуса (400, 401, 402, 408, 422, 429, 500, 502, 503, 504). Это показывает характеристики REST в production AI-продукте без необходимости в SOAP-контрактах или сложности gRPC. Не демонстрация HATEOAS, но практичный API уровня 2, который легко интегрировать и бизнес-командам, и разработчикам.
Почему характеристики REST API важны для бизнес-команд
Продажи, операции, e-commerce — ни одна из этих команд не пишет API-код. Но вы выбираете поставщиков, подключаете инструменты и строите автоматизацию — и качество REST API напрямую влияет на то, насколько болезненными (или безболезненными) будут эти интеграции.
Интеграция инструментов: когда ваша CRM синхронизируется с платформой маркетинговой автоматизации, именно дизайн REST API определяет, будет ли синхронизация надёжной или хрупкой. Salesforce Marketing Cloud REST API управляет контактами, кампаниями, journeys и push-уведомлениями через предсказуемые ресурсные конечные точки. Если эти конечные точки следуют REST-соглашениям, ваша RevOps-команда может автоматизировать процессы без костылей.
Ecommerce-операции: REST-ресурсы Shopify для fulfillment управляют заказами на отгрузку, трек-номерами и состояниями отправки. От этого слоя зависят приложения для доставки и инструменты исполнения заказов. Когда API хорошо спроектирован — правильные коды статуса, кэшируемые данные каталога, понятные сообщения об ошибках — логистический пайплайн работает гладко. Когда нет — появляются загадочные сбои в 2 часа ночи.
Оценка поставщиков: знание 6 ограничений даёт вам практический чек-лист:
- Использует ли API стандартные коды статуса или каждая ошибка выглядит как 200 OK?
- Достаточно ли конкретны ошибки, чтобы ваш инструмент автоматизации мог восстановиться?
- Есть ли понятная документация по rate limits, пагинации и аутентификации?
- Можно ли кэшировать типовые ответы, чтобы снизить нагрузку?
Извлечение данных и автоматизация: инструменты вроде Thunderbit используют REST-архитектуру, чтобы позволить бизнес-пользователям извлекать структурированные данные с сайтов, PDF и изображений — а затем экспортировать их в Google Sheets, Airtable, Notion или Excel. Расширение Chrome AI Web Scraper от Thunderbit скрывает сложность за интерфейсом в 2 клика, но под капотом именно REST-принципы — безсостояние запросы, JSON-ответы, стандартные ошибки — делают интеграционный слой надёжным.
Ещё одна важная цифра: в отчёте Postman за 2025 год выяснилось, что только 24% разработчиков активно проектируют API с учётом AI-агентов, тогда как 51% опасаются несанкционированных или чрезмерных вызовов API со стороны AI-агентов. По мере того как автоматизация и AI-воркфлоу становятся стандартом в бизнес-командах, предсказуемые REST-паттерны, ключи API с принципом наименьших привилегий и ограничения скорости — это уже не только забота разработчиков, но и фактор операционного риска.
Как Thunderbit применяет принципы REST для бизнес-пользователей
Мы создавали Thunderbit с допущением, что большинство наших пользователей никогда не будут читать спецификацию REST — и не должны этого делать. Но решения, которые делают Thunderbit простым в использовании, основаны на тех же REST-характеристиках, о которых говорится в этой статье.
Вот кратко, как это работает на практике:
- Установите расширение Chrome из Chrome Web Store и откройте любой сайт, PDF или изображение, с которого хотите извлечь данные.
- Нажмите «AI Suggest Fields» — AI Thunderbit прочитает страницу и предложит структурированную таблицу столбцов: названия товаров, цены, email-адреса — всё, что есть на странице.
- При необходимости скорректируйте столбцы, затем нажмите «Scrape». Thunderbit автоматически обработает пагинацию, подстраницы и динамический контент.
- Экспортируйте данные в Google Sheets, Airtable, Notion, CSV или Excel — бесплатно, без paywall.
Для разработчиков и автоматизированных сценариев Open API от Thunderbit предоставляет /distill (чистое извлечение в Markdown) и /extract (структурированное извлечение данных) как REST-подобные POST-конечные точки с JSON-телом и стандартными HTTP-кодами ошибок. В терминах модели зрелости Ричардсона это уверенный уровень 2 — ресурсы, правильные методы, осмысленные коды статуса.
Если вы изучаете веб-скрейпинг или извлечение данных шире, у нас есть подробные руководства по AI web scraping, web scraping без кода и что такое веб-скрейпинг на самом деле.
Главные выводы
- REST — это архитектурный стиль, а не протокол. Он определяет 6 ограничений — клиент-сервер, безсостояность, кэшируемость, единый интерфейс, слоистую систему и опциональный code-on-demand — которые направляют проектирование API.
- Большинство «RESTful» API не являются полностью RESTful. Основная масса находится на уровне 2 по Ричардсону (ресурсы + HTTP-глаголы + коды статуса). HATEOAS и code-on-demand реализуются редко.
- Модель зрелости Ричардсона — лучший инструмент самооценки. Она заменяет бинарный вопрос «REST или нет» на практический спектр (уровни 0–3).
- Распространённые ошибки — 200 OK при ошибках, POST для всего, отсутствие кэш-заголовков — по-прежнему повсеместны. Понимание ограничений помогает замечать и исправлять эти анти-паттерны.
- REST vs SOAP vs GraphQL vs gRPC — это не про «лучший», а про соответствие задаче. REST доминирует в публичных API и CRUD-интеграциях. GraphQL подходит для сложных фронтендов. gRPC силён во внутренних микросервисах. SOAP сохраняется в enterprise и legacy-контекстах.
- Бизнес-командам полезно понимать характеристики REST при оценке поставщиков, подключении инструментов и построении автоматизации. Инструменты вроде Thunderbit применяют REST-принципы, чтобы сделать извлечение данных доступным без технической экспертизы.
FAQ
Каковы 6 характеристик REST API?
6 ограничений REST: (1) разделение клиент-сервер, (2) безсостояность, (3) кэшируемость, (4) единый интерфейс, (5) слоистая система и (6) code-on-demand (опционально). Первые пять обязательны, чтобы API считался RESTful по исходному определению Филдинга.
В чём разница между REST и RESTful?
REST — это архитектурный стиль, то есть набор ограничений проектирования, определённый Роем Филдингом. «RESTful» описывает API, который следует этим ограничениям. На практике многие API с ярлыком «RESTful» соответствуют им лишь частично: обычно они реализуют ресурсы, HTTP-методы и коды статуса, но пропускают HATEOAS и code-on-demand.
Все ли REST API соблюдают каждое REST-ограничение?
Нет. Большинство production API соблюдают разделение клиент-сервер, безсостояность и базовый единый интерфейс (ресурсы + HTTP-глаголы). Кэшируемость и слоистая система внедряются непоследовательно. HATEOAS встречается редко, а code-on-demand почти никогда не используется в JSON API.
В чём разница между REST и GraphQL?
REST предоставляет ресурсы через несколько конечных точек со стандартными HTTP-методами (GET, POST, PUT, DELETE). GraphQL обычно использует одну конечную точку, где клиент в запросе указывает ровно те поля, которые ему нужны. У REST сильнее нативное HTTP-кэширование; GraphQL даёт больше гибкости для сложных вложенных данных и уменьшает избыточную выборку.
Что такое HATEOAS, и кто-нибудь вообще его использует?
HATEOAS (Hypermedia as the Engine of Application State) означает, что ответы API включают ссылки, которые подсказывают клиенту, какие действия доступны дальше, — так клиент может перемещаться по API, не хардкодя каждую конечную точку. Это центральная часть видения REST у Филдинга (уровень 3 по Ричардсону), но на практике очень немногие публичные API это реализуют. Большинство команд останавливаются на уровне 2 и вместо этого полагаются на документацию и SDK.
Попробовать Thunderbit для AI web scraping
Попробовать Thunderbit для AI web scraping Get Started Free
Узнать больше
