Что такое уровни зрелости REST API (модель Ричардсона)?

Ответ

Уровни зрелости REST (Richardson Maturity Model, RMM) — это модель, оценивающая, насколько веб-API соответствует архитектурным ограничениям REST. Она включает четыре уровня, от наименее к наиболее "RESTful".

Уровень Название Ключевая характеристика Пример HTTP-запроса
0 Swamp of POX (Болото POX) Использует HTTP только как транспортный протокол. Обычно один URI (например, /api) и один метод (чаще всего POST). POST /api с телом {"action": "getUser", "id": 123}
1 Resources (Ресурсы) Вводит понятие отдельных ресурсов (сущностей). Разные URI для разных сущностей. POST /users/123 (для получения данных)
2 HTTP Verbs (HTTP-глаголы) Использует HTTP-методы (GET, POST, PUT, DELETE) по их семантике и коды состояния HTTP. GET /users/123
3 Hypermedia Controls (Гипермедиа, HATEOAS) Ответы API содержат ссылки (links) на возможные следующие действия, что делает API самоописываемым. GET /users/123 возвращает данные пользователя со ссылками на его заказы.

Пример ответа уровня 3 (HATEOAS):

{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com",
  "_links": {
    "self": { "href": "/users/123" },
    "orders": { "href": "/users/123/orders" },
    "update": { "href": "/users/123", "method": "PUT" },
    "delete": { "href": "/users/123", "method": "DELETE" }
  }
}

Почему это важно? Уровни 2 и 3 обеспечивают лучшую предсказуемость, кэшируемость, масштабируемость и независимость клиента от конкретной структуры URI, что является ключевой целью REST.

Ответ 18+ 🔞

А, слушай, про эти ваши REST-уровни зрелости! Это ж классика, как «Муму», только про апишки. Сейчас объясню, как есть, без соплей.

Представь, что ты пришёл в огромную, блядь, контору — ну, как к той барыне у Тургенева. И от того, как ты там будешь общаться, зависит, останешься ты с носом или всё получишь.

Уровень 0 — Болото POX (The Swamp of POX) Это пиздец и бардак, как Герасим до собаки. Одна дверь на всех, и ты тупишь в неё, как немой. Подходишь к единственной конторе /api и начинаешь орать в трубку: «Эй, дай мне пользователя 123!». И неважно, что ты хочешь — получить, удалить или обнять — ты всё через одно место и одним криком (POST) делаешь. Полный распиздяйский подход.

POST /api
Content-Type: application/json

{"action": "getUser", "id": 123}

Это как кричать «Мууу!» на всё подряд. Никакой структуры, нихуя не понятно.

Уровень 1 — Ресурсы Тут уже появляется намёк на мозги. Появились разные комнаты для разных дел. Хочешь про пользователей — иди в комнату /users. Хочешь про заказы — в /orders. Но, блядь, способ общения всё тот же — ты всё равно стоишь под дверью и орёшь POST, чтобы просто получить данные. Уже лучше, но всё ещё мудачество.

POST /users/123

Типа «я пришёл в комнату пользователей, к конкретному челу под номером 123, и кричу ему в ухо, чтобы он мне рассказал о себе». Нелепо, но хоть комнаты разные.

Уровень 2 — HTTP Глаголы А вот тут уже начинается цивилизация, ёпта! Ты не просто приходишь в комнату — ты используешь правильные слова. Хочешь узнать что-то — говоришь вежливо GET. Хочешь создать — POST. Обновить — PUT. Удалить — DELETE. И контора (сервер) тебе отвечает понятными кодами: «200 — ок», «404 — не нашёл», «500 — я обосрался».

GET /users/123

Вот это уже похоже на диалог! Ты чётко говоришь: «Дай-ка мне данные пользователя 123». И тебе их дают. Красота! Кэширование работает, логика ясна. Большинство апишек на этом и останавливаются, и то хорошо.

Уровень 3 — Гипермедиа (HATEOAS) А это, блядь, высший пилотаж! Это когда Герасим не просто молча топит собаку, а получает инструкцию с картой и ссылками «куда идти дальше». Ты делаешь запрос, и в ответе тебе не только данные, но и подсказки: «А вот тут можешь посмотреть его заказы, а тут — обновить, а тут — удалить». Клиенту не нужно заранее знать всю структуру URL-ов, он просто ходит по ссылкам, как по гиперссылкам на сайте. Самоописываемая система, мечта!

{
  "id": 123,
  "name": "Василий Пупкин",
  "email": "vasya@example.com",
  "_links": {
    "self": { "href": "/users/123" },
    "orders": { "href": "/users/123/orders" },
    "update": { "href": "/users/123", "method": "PUT" },
    "delete": { "href": "/users/123", "method": "DELETE" }
  }
}

Видишь эти _links? Это как та самая записка «куда идти дальше», только не «утопить в пизду», а полезные действия. Клиент становится независимым — сервер сам ведёт его за ручку.

Так зачем этот весь цирк? А затем, чувак, что уровни 2 и 3 — это и есть настоящий REST, а не его куцая пародия. Это даёт:

  • Предсказуемость. GET — не меняет данные, DELETE — удаляет. Всё по полочкам.
  • Кэшируемость. Прокси и браузеры могут кэшировать ответы на GET-запросы, потому что они идемпотентные. Скорость летит вверх.
  • Масштабируемость. Чёткое разделение ответственности.
  • Независимость клиента. Особенно на 3-м уровне — URL-ы могут меняться, но клиент будет находить нужные действия по отношениям (rel), а не по жёстко зашитым путям.

Короче, стремись хотя бы ко второму уровню, а третий — это идеал, который в жизни встречается реже, чем честный человек. Но знать про него надо, а то будешь как тот немой Герасим — силы дохуя, а объяснить ничего не можешь, кроме «Муму».