[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-rest-api-kakie-ogranicheniya-constraints-opredelyaet-rest":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":16,"progress":17,"seo":18},1110,"kakie-ogranicheniya-constraints-opredelyaet-rest",34,"rest-api","REST API","🌐","Какие ограничения (constraints) определяет REST?","REST определяет шесть архитектурных ограничений, пять из которых обязательны и одно опциональное:\n\n1. **Клиент-сервер (Client-Server)** — разделение ответственности: клиент отвечает за пользовательский интерфейс, сервер — за хранение и обработку данных. Это позволяет независимо развивать клиентскую и серверную части.\n\n2. **Отсутствие состояния (Stateless)** — каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для обработки. Сервер не хранит состояния клиента между запросами. Сессия хранится на стороне клиента (например, в виде токена).\n   - упрощается масштабирование (любой сервер может обработать любой запрос);\n   - повышается надёжность;\n   - упрощается мониторинг.\n\n3. **Кэширование (Cacheable)** — ответы сервера должны явно или неявно указывать, могут ли они быть кэшированы. Правильное кэширование снижает нагрузку на сервер и улучшает производительность клиента.\n\n4. **Единообразие интерфейса (Uniform Interface)** — ключевое ограничение REST, включающее четыре подпринципа:\n   - Идентификация ресурсов — каждый ресурс идентифицируется через URI.\n   - Манипуляция ресурсами через представления — клиент работает с представлениями ресурсов (JSON, XML), а не с самими ресурсами напрямую.\n   - Самоописательные сообщения — каждое сообщение содержит достаточно информации для его обработки (Content-Type, метод, заголовки).\n   - HATEOAS (Hypermedia as the Engine of Application State) — клиент взаимодействует с приложением полностью через гипермедиа, предоставляемую сервером.\n\n5. **Многоуровневая система (Layered System)** — архитектура может состоять из нескольких уровней (прокси, балансировщики, шлюзы). Клиент не знает, взаимодействует ли он напрямую с сервером или с промежуточным уровнем.\n\n6. **Код по требованию (Code on Demand) — опционально** — сервер может расширять функциональность клиента, передавая исполняемый код (например, JavaScript). Это единственное опциональное ограничение.\n\n> **На собеседовании:** нужно перечислить все шесть ограничений и отметить, что Code on Demand — опциональное. Частая ошибка — забыть про Uniform Interface или не раскрыть его четыре подпринципа.","","junior",[15],"rest",[],null,{"title":19,"description":20,"ogTitle":19,"ogDescription":20,"keywords":21,"schemaAnswer":20,"featuredSnippetReady":22},"Какие ограничения (constraints) определяет REST? — Gymterview","REST определяет шесть архитектурных ограничений, пять из которых обязательны и одно опциональное:",[15,13],true]