REST (Representational State Transfer) — это архитектурный стиль для создания API, использующих HTTP для коммуникации. Чтобы считаться RESTful, API должен следовать шести ключевым ограничениям:
- Клиент-сервер: отделяет пользовательский интерфейс от хранения и обработки данных. Это позволяет каждой стороне развиваться независимо.
- Без состояния: каждый запрос содержит всю необходимую информацию для его обработки; Сервер не хранит состояние сессии между запросами.
- Единый интерфейс: Согласованное имя ресурсов и форматы по всему API, например, «/products», «/users».
- Кэшируемый: Ответы явно указывают, можно ли их кэшировать (например, Cache-Control) для повышения производительности.
- Многоуровневая система: Запросы могут проходить через несколько уровней (балансировщики нагрузки, сервисы аутентификации и т.д.), прежде чем достичь сервера API, но для клиента они выглядят как единая конечная точка.
- Код по требованию (необязательно): сервер может отправлять исполняемый код (например, JavaScript) клиенту для расширения его функциональности.
Dmitrii_Mihalev
5 методов аутентификации REST API
1. Базовая аутентификация: клиенты включают имя пользователя и пароль, закодированные по Base64, в каждом заголовке запроса, что просто, но небезопасно, так как учетные данные передаются в открытом виде. Полезно для быстрых прототипов или внутренних сервисов через защищённые сети.
2. Аутентификация сессии: после входа сервер создаёт запись сессии и выпустит куки. Последующие запросы отправляют этот куки, чтобы сервер мог проверить состояние пользователя. Используется в традиционных веб-приложениях.
3. Аутентификация токенов: клиенты проходят аутентификацию один раз, чтобы получить подписанный токен, затем представляют токен при каждом запросе на бессостоятельную аутентификацию. Используется в приложениях с одной страницей и современных API, требующих масштабируемой бессостоятельной аутентификации.
4. Аутентификация на основе OAuth: клиенты получают токен доступа через авторизацию от провайдера OAuth, а затем используют этот токен для вызова серверов ресурсов от имени пользователя. Используется в случаях сторонних интеграций или приложений, требующих делегированного доступа к данным пользователей.
5. Аутентификация ключа API: Клиенты представляют заранее определённый ключ (часто в заголовках или строках запроса) с каждым запросом. Сервер проверяет ключ для авторизации доступа. Используется в API service-to-service или machine-to-machine, где достаточно простых проверок учетных данных.
Комментарии (2)
- Клиент-сервер: отделяет пользовательский интерфейс от хранения и обработки данных. Это позволяет каждой стороне развиваться независимо.
- Без состояния: каждый запрос содержит всю необходимую информацию для его обработки; Сервер не хранит состояние сессии между запросами.
- Единый интерфейс: Согласованное имя ресурсов и форматы по всему API, например, «/products», «/users».
- Кэшируемый: Ответы явно указывают, можно ли их кэшировать (например, Cache-Control) для повышения производительности.
- Многоуровневая система: Запросы могут проходить через несколько уровней (балансировщики нагрузки, сервисы аутентификации и т.д.), прежде чем достичь сервера API, но для клиента они выглядят как единая конечная точка.
- Код по требованию (необязательно): сервер может отправлять исполняемый код (например, JavaScript) клиенту для расширения его функциональности.
1. Базовая аутентификация: клиенты включают имя пользователя и пароль, закодированные по Base64, в каждом заголовке запроса, что просто, но небезопасно, так как учетные данные передаются в открытом виде. Полезно для быстрых прототипов или внутренних сервисов через защищённые сети.
2. Аутентификация сессии: после входа сервер создаёт запись сессии и выпустит куки. Последующие запросы отправляют этот куки, чтобы сервер мог проверить состояние пользователя. Используется в традиционных веб-приложениях.
3. Аутентификация токенов: клиенты проходят аутентификацию один раз, чтобы получить подписанный токен, затем представляют токен при каждом запросе на бессостоятельную аутентификацию. Используется в приложениях с одной страницей и современных API, требующих масштабируемой бессостоятельной аутентификации.
4. Аутентификация на основе OAuth: клиенты получают токен доступа через авторизацию от провайдера OAuth, а затем используют этот токен для вызова серверов ресурсов от имени пользователя. Используется в случаях сторонних интеграций или приложений, требующих делегированного доступа к данным пользователей.
5. Аутентификация ключа API: Клиенты представляют заранее определённый ключ (часто в заголовках или строках запроса) с каждым запросом. Сервер проверяет ключ для авторизации доступа. Используется в API service-to-service или machine-to-machine, где достаточно простых проверок учетных данных.