Почему аутентификация на основе форм НЕ считается RESTful?

Question

Хотя я «думаю», я понимаю это, мне нужна ясность. С аутентификацией PURE Restful все становится немного громоздким, а использование форм очень помогает с пользовательским интерфейсом приложения (т. Е. Иметь отдельную страницу входа в систему, ссылки на забытый пароль, более легкий выход из системы? И т. Д.)

Теперь Формы приходят, и некоторые люди говорят "не успокаивается" - что в них "не успокаивается"? Неужели нет соответствующего логина , так сказать? Или это заставляет меня что-то еще пропустить?

Примечание: если кто-то создает сеансы с ними, это совсем другое дело. Я больше заинтересован в том, чтобы знать «почему», они называются спокойными? Просто поиск в поиске «Проверка подлинности на основе форм против спокойной проверки подлинности» выдает немало хитов.

Можно использовать эти «формы» для аутентификации и передачи токенов для приложения для хранения в cookie-файлах и т. Д., Что, на мой взгляд, совершенно успокоительно (при условии криптографической безопасности и т. Д.) ...

Answer 1

Нет ничего плохого в отправке ваших учетных данных, возможно, через форму, для аутентификации.Проблема заключается в том, что большинство систем на основе форм полагаются на сеансы, поэтому требуется, чтобы вы входили в систему только «один раз».

Сеансы находятся в состоянии сервера, что нарушает ограничение без сохранения состояния архитектуры REST.

Есливам нужно отправлять учетные данные каждый раз, вы можете либо включить их в полезную нагрузку (то есть, используя форму), либо использовать заголовок авторизации HTTP.

Если вы включите их в полезную нагрузку, вы можете включитьони в теле, но только для POST или PUT, а не для GET или DELETE (так как они не имеют тел).

Если вы включите их в URL как часть параметров запроса, тогдаURL больше не обязательно представляет реальный ресурс.Одним из других принципов является то, что URL соответствует ресурсу.Добавление внеполосной информации (такой как учетные данные) в параметры запроса, которые немного ограничивают.

Итак, для системы REST через HTTP лучше использовать существующий механизм HTTP-авторизации, чем разрабатыватьчто-то другое.Вы также можете использовать специфичные для клиента SSL-сертификаты, которые также отлично работают.

Answer 2

Отличный вопрос. Я думаю, что пуристы RESTful, скорее всего, скажут, что наличие URI, связанного с действием , а не ресурсом - это то, что делает аутентификацию на основе форм не RESTful, на что вы сами указали.

Честно говоря, я думаю, что идея 100% чистого RESTful-приложения - это своего рода утопический идеал, когда речь идет о веб-приложениях. Однако я полагаю, что это достижимо для веб-служб RESTful, поскольку вызывающие приложения могут передавать учетные данные с заголовком запроса.

В конце концов, я думаю, что пока ваше приложение работает , это нормально, и вам не нужно беспокоиться о том, является ли оно чисто RESTful.

Это мои 0,02 доллара.

Answer 3

С этот ответ :

Чтобы быть RESTful, каждый HTTP-запрос должен содержать достаточно информации, чтобы его получатель мог обработать его, чтобы он был в полной гармонии с природой без состоянияHTTP.

Дело не в том, что аутентификация на основе форм не является RESTful - вовсе не RESTful иметь сеанс вообще .RESTful способ отправить учетные данные с каждым запросом.Однако это можно легко подслушать, но HTTPS / SSL / TLS закрывает эту дыру.

Answer 4

Аутентификация на основе форм не использует методы аутентификации, встроенные в HTTP (например, базовая аутентификация, дайджест-аутентификация).

Пуристы REST попросят вас по возможности использовать функциональность, встроенную в HTTP. Несмотря на то, что аутентификация на основе форм чрезвычайно распространена, она не является частью официального протокола. Таким образом, пурист REST рассматривает аутентификацию на основе форм как пример «построения функциональности поверх HTTP , когда эта функциональность уже существует внутри самого HTTP ».