REST GET запросы, глаголы и apikey

Question

Я хочу создать гибкий сервер API Rest.Я позволю клиентам проходить аутентификацию, используя HTTP или APIKEY.

Мой вопрос: как правильно добавить apikey в запрос GET?Моя проблема в том, что apikey загрязняет URL.

Я представляю что-то вроде этого: / book / 1 / apikey / s4cr4t!

Answer 1

На мой взгляд, вы должны использовать только заголовок авторизации.Вот для чего он нужен.

Поместить его в URL - плохая идея, потому что:

a) как вы сказали, это загрязняет URL
b) если вы решите использовать SSLв целях безопасности API все равно будет отображаться в лог-файлах
c) кэши в конечном итоге создадут несколько копий одного и того же представления, по одной для каждого ключа API.

Для получения дополнительной информации о создании собственной схемы авторизации перейдите здесь .

Answer 2

Учетные данные могут быть переданы с использованием заголовка Authorization:

GET http://domain.com:/book/1
Authorization: apikey="s4cr4t"

Answer 3

Все зависит от того, как далеко вы хотите пойти, но механика остается неизменной:

Контекст

Цель состоит в том, чтобы идентифицировать клиента с некоторым уровнембезопасность.(Примечание. Безопасность - это еще одно подробное обсуждение).Помните об этом, если «функции» REST не содержат состояний: это означает, что на сервере нет состояния сеанса, кроме ресурсов.Чтобы клиент оставался без состояния, он должен предоставлять по каждому запросу достаточно информации, чтобы запрос был независимым.Он должен дать серверу способ идентифицировать клиента, такой как имя пользователя / пароль, ключ API или токен.

У вас есть несколько вариантов сделать это, вот некоторые из них:

Добавьте заголовки HTTP для идентификации клиента

Здесь можно использовать заголовок авторизации и отправлять его с каждым запросом.Существуют различные схемы аутентификации, но придерживайтесь стандартных, таких как Basic Auth .Здесь вы, вероятно, будете придерживаться SSL.Процесс аутентификации генерирует своего рода токен, если хотите.

Вы также можете использовать куки.Файл cookie должен содержать никакой информации , за исключением того, что он является «указателем или ключом» к ресурсу сеанса с сохранением состояния на вашем сервере (примечание: сеанс это ресурс, который является «законным»).Вы можете создать этот ресурс, выполнив PUT (+ info) с ответом 200 OK или POST (+ info) с ответом 201 Created и Location: / session / 123334.Затем сеанс может быть проверен сервером, таким как тайм-аут, действительный IP-адрес клиента, ключ API и т. Д.

С помощью описанного выше метода вы также можете определить заголовок клиента, такой как Api-Key: XXXX.Но тогда вы ограничиваете себя специальным клиентом.Set-Cookie являются «хорошо известными» заголовками, поэтому браузер будет работать с ними прозрачно.Затем процесс аутентификации может быть выполнен путем перехода по ссылкам и заполнения форм (PUT + POST) для аутентификации (создания ресурса сеанса).

Кодирование идентификатора в содержимом

Здесь вы можете делать то, что вы хотите тоже.Просто добавьте поле / токен / id к своему контенту и позвольте серверу проверить его.

RESTful API выполняет поток приложений путем разрешения ссылок.См. Также HATEOAS и Слова Филдинга .Это также применяется, когда у вас есть отдельный процесс входа в приложение.

Не кодируйте никакие данные в URI.(Внешняя информация)