REST API
§§IBT7§§¶@definition¶REST API — стиль проектирования API на основе ресурсов, HTTP-методов и единообразного интерфейса.¶@plain¶REST API — интерфейс, построенный вокруг ресурсов и стандартной семантики HTTP: клиент обращается к URI, использует методы и получает представление состояния. REST — архитектурный стиль, поэтому наличие JSON и HTTP ещё не гарантирует соблюдение его ограничений.¶@use¶При проектировании определяют ресурсы, методы, статусы, схемы данных, аутентификацию и авторизацию на уровне каждого объекта. В защите учитывают массовое назначение полей, перебор идентификаторов, лимиты, идемпотентность, журналирование и версионирование.¶@example¶Запрос PATCH /accounts/123 проверяет не только действительность токена, но и право пользователя изменять именно счёт 123 и только разрешённые поля. Повтор запроса регистрируется с correlation ID, а лишнее поле роли отклоняется схемой.¶@compare¶RPC¦¦RPC описывает вызов операций, а GraphQL позволяет клиенту формировать структуру запроса.¶@steps¶Описать ресурс¦API задаёт URI, представление, допустимые операции и правила перехода состояния.¤Принять запрос¦Шлюз проверяет транспорт, формат, размер, квоты и подлинность клиента.¤Авторизовать объект¦Сервис проверяет действие, конкретный объект и разрешённые поля, а не только наличие токена.¤Вернуть результат¦Ответ использует корректный статус и схему, исключает лишние данные и связывается с журналом по идентификатору.¶@resources¶Курсы по AppSec¦https://ibcourses.ru/appsec-kursy¦Курс¶@related¶¶@faq¶REST API обязан использовать JSON?¦Нет. Формат представления согласуется через HTTP; JSON распространён, но не является определяющим признаком REST.¤Почему проверка роли недостаточна?¦Пользователь с разрешённой ролью может обратиться к чужому объекту; нужна объектная и полевая авторизация.¤Нужно ли версионировать API?¦Изменения контракта требуют управляемой совместимости; способ версионирования выбирают заранее и документируют жизненный цикл версий.