REST (Representational State Transfer) — это архитектурный стиль для сетевых приложений, определённый Роем Филдингом. Это не протокол и не стандарт — это набор ограничений (constraints), следование которым делает API масштабируемым, кэшируемым и лёгким для развития. «RESTful» API моделирует всё как ресурсы (resources) (пользователи, заказы, товары), идентифицируемые через URI, и манипулирует ими стандартными HTTP-методами.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
URI /users/42 называет ресурс; GET — это действие; JSON — представление. Эта комбинация — существительные в пути, глаголы как HTTP-методы — и есть суть REST.
REST — доминирующий стиль для веб-API, поэтому интервьюеры используют этот вопрос, чтобы проверить, понимаете ли вы, почему он работает, а не просто умеете его назвать. Два ограничения, которые важнее всего на практике, — это statelessness (каждый запрос самодостаточен, поэтому можно поставить любое число серверов за балансировщик и масштабироваться горизонтально без sticky-сессий) и uniform interface (предсказуемые, ресурсо-ориентированные URL плюс стандартные HTTP-методы и коды состояния, а значит клиентам не нужна собственная логика под каждый endpoint). Сильный ответ связывает ограничения с конкретными выгодами — statelessness даёт масштабирование, cacheability снижает нагрузку, layered system позволяет вставлять CDN и шлюзы — и отмечает, что большинство «REST» API прагматичны, а не полностью RESTful (мало кто реализует HATEOAS). Понимание этих ограничений — фундамент для любого другого решения в проектировании REST, от выбора кодов состояния до версионирования.
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать