Ну, например посмотреть, что в этом браузере делает google analytics. Можно и так, конечно, но неудобно.
Плюс быть уверенным, что блоб получен именно из публичных исходников, а не как обычно с волшебными закладками.
Плюс мне может быть интересно, что они используют и как именно они что-то делают — я мог бы взять и посмотреть код интересующего компонента без дополнительных проблем.
Учтите — не обязательно каждому пользователю смотреть на 5% кода. Достаточно небольшому проценту пользователей посмотреть каждому маленький кусочек кода, чтобы в целом значительно улучшить ситуацию и свести к минимуму вероятность наличия там откровенной фигни (это не касается серьёзных закладок, конечно — от них нужен тщательный ревью, который, кстати, тоже гораздо удобнее делать с открытыми проектами).
И да, я периодически присылаю патчи в то, чем пользуюсь. Для этого необязательно читать все исходники — достаточно иметь возможность найти конкретное место, которое меня не устраивает. А тут не только публичного репозитория с пулл реквестами, тут вообще исходников, кажется, нет.
Вопрос не в реализации, а в семантике. Если есть стандартизованный хидер, предназначенный специально для авторизационных токенов, то токены там и должны лежать в большинстве случаев.
То есть — если я увижу незнакомый сервис, то я буду с большей вероятностью ждать, что токен лежит именно в хидере авторизации, потому что это ближе к стандарту, соответственно поддержка сервиса для меня будет чуточку дешевле.
Клиент делает запрос, к примеру:
POST service.com/token/ передаешь ему логин пароль, сервис производит аутентификацию и в ответ отдает тебе токен. Токен хранится в базе и имеет разрешение/запреты на определенные действия.
Дальше клиент делает те запросы которые ему нужны и в заголовке передает токен:
GET service.com/car/1
PUT service.com/car/1 и т.д.
В итоге получается, что сервис не хранит твое состояние, ты создал новый ресурс, а потом просто запрашиваешь или изменяешь другие.
А очень просто. Сначала выполняем аутентификацию. При успешном входе, клиенту возвращаеться специально сгенерированный токен по которому могут идентифицировать клиента на сервере. Далее при каждом запросе к REST сервису, добавляется дополнительный заголовок «Authorization» в котором вы указываете тип авторизации и полученый токен.
Просто надо понимать, что есть:
1. Входные данные
2. Некие бизнес-данные
3. Некие данные о состоянии самого сервиса.
И пока данных о состоянии сервиса нет и они не влияют на его поведение — сервис остается stateless.
Грубо говоря:
Если сервис возвращает, например, список пользователей, но после 100-го запроса внезапно переключает некий флаг и начинает возвращать список пользователей с каким-нибудь фильтром или вообще какой-нибудь другой список — то это stateful service.
Если же он всегда возвращает список пользователей, но при этом кол-во пользователей в системе меняется и результат запроса естественно тоже меняется, то это не мешает сервису быть stateless.
1) Ну смотрите:
Я делаю GET somehost/someresource/100500
Далее кто-то делает POST somehost/someresource/100500 и изменяет ресурс который лежит по данному uri.
Когда я сделают такой же GET somehost/someresource/100500 я получу уже совсем другой результат. Это же не значит, что сервис уже не RESТ? А все потому что изменилось не состояние сервиса, а состояние некоего внешнего по отношению к сервису ресурса.
А поведение осталось то же — берем ресурс из БД, сериализуем и возвращаем пользователю.
А вот пример сервиса с воркфлоу: например у меня есть некий документооборот и я хочу создать некий ресурс-запись и привязать к нему некий набор файлов. С воркфлоу-сервисом возможен следующий вариант:
1. Я вызываю у сервиса некий метод «Создай мне ресурс», сервис его создает и запоминает состояние для моей сессии, что я только что просил у него создать ресурс и запоминает например некий внутренний идентификатор.
2. Несколькими последовательными запросами я заливаю файлы, причем сервис привязывает их к той записи, которую только что для меня создал.
Сценарий для типичной веб-разработки странный, но довольно-таки часто встречается в энтерпрайзном документообороте, что и породило разнообразные state machine движки.
Обратите внимание, что сервис по сути поменял интерфейс между шагом 1 и 2, как и положено конечному автомату.
2) Простой пример — токен может сразу нести в себе информацию о том, какими правами обладает пользователь или к какому множеству данных он может получить доступ, что позволяет их проверить без лишних запросов к той же БД. Так например работает Active Directory, что спасает в сильно распределенных системах.
Ну, например посмотреть, что в этом браузере делает google analytics. Можно и так, конечно, но неудобно.
Плюс быть уверенным, что блоб получен именно из публичных исходников, а не как обычно с волшебными закладками.
Плюс мне может быть интересно, что они используют и как именно они что-то делают — я мог бы взять и посмотреть код интересующего компонента без дополнительных проблем.
Учтите — не обязательно каждому пользователю смотреть на 5% кода. Достаточно небольшому проценту пользователей посмотреть каждому маленький кусочек кода, чтобы в целом значительно улучшить ситуацию и свести к минимуму вероятность наличия там откровенной фигни (это не касается серьёзных закладок, конечно — от них нужен тщательный ревью, который, кстати, тоже гораздо удобнее делать с открытыми проектами).
И да, я периодически присылаю патчи в то, чем пользуюсь. Для этого необязательно читать все исходники — достаточно иметь возможность найти конкретное место, которое меня не устраивает. А тут не только публичного репозитория с пулл реквестами, тут вообще исходников, кажется, нет.
А вообще — см. https://www.gnu.org/philosophy/free-sw.html
Хидер Authorization введен специально для авторизации (RFC 2617).
Cookie — это механизм хранения информации о состоянии сессии (RFC 6265).
Лично мне разница очевидна.
То есть — если я увижу незнакомый сервис, то я буду с большей вероятностью ждать, что токен лежит именно в хидере авторизации, потому что это ближе к стандарту, соответственно поддержка сервиса для меня будет чуточку дешевле.
Клиент делает запрос, к примеру:
POST service.com/token/ передаешь ему логин пароль, сервис производит аутентификацию и в ответ отдает тебе токен. Токен хранится в базе и имеет разрешение/запреты на определенные действия.
Дальше клиент делает те запросы которые ему нужны и в заголовке передает токен:
GET service.com/car/1
PUT service.com/car/1 и т.д.
В итоге получается, что сервис не хранит твое состояние, ты создал новый ресурс, а потом просто запрашиваешь или изменяешь другие.
Или я что-то путаю?)
GET www.google.com/cse/api/default/cse/
Authorization: GoogleLogin auth=IM6F7Cx2fo0TAiwlhNVdSE8Ov8hw6aHV
1. Входные данные
2. Некие бизнес-данные
3. Некие данные о состоянии самого сервиса.
И пока данных о состоянии сервиса нет и они не влияют на его поведение — сервис остается stateless.
Грубо говоря:
Если сервис возвращает, например, список пользователей, но после 100-го запроса внезапно переключает некий флаг и начинает возвращать список пользователей с каким-нибудь фильтром или вообще какой-нибудь другой список — то это stateful service.
Если же он всегда возвращает список пользователей, но при этом кол-во пользователей в системе меняется и результат запроса естественно тоже меняется, то это не мешает сервису быть stateless.
Я делаю GET somehost/someresource/100500
Далее кто-то делает POST somehost/someresource/100500 и изменяет ресурс который лежит по данному uri.
Когда я сделают такой же GET somehost/someresource/100500 я получу уже совсем другой результат. Это же не значит, что сервис уже не RESТ? А все потому что изменилось не состояние сервиса, а состояние некоего внешнего по отношению к сервису ресурса.
А поведение осталось то же — берем ресурс из БД, сериализуем и возвращаем пользователю.
А вот пример сервиса с воркфлоу: например у меня есть некий документооборот и я хочу создать некий ресурс-запись и привязать к нему некий набор файлов. С воркфлоу-сервисом возможен следующий вариант:
1. Я вызываю у сервиса некий метод «Создай мне ресурс», сервис его создает и запоминает состояние для моей сессии, что я только что просил у него создать ресурс и запоминает например некий внутренний идентификатор.
2. Несколькими последовательными запросами я заливаю файлы, причем сервис привязывает их к той записи, которую только что для меня создал.
Сценарий для типичной веб-разработки странный, но довольно-таки часто встречается в энтерпрайзном документообороте, что и породило разнообразные state machine движки.
Обратите внимание, что сервис по сути поменял интерфейс между шагом 1 и 2, как и положено конечному автомату.
2) Простой пример — токен может сразу нести в себе информацию о том, какими правами обладает пользователь или к какому множеству данных он может получить доступ, что позволяет их проверить без лишних запросов к той же БД. Так например работает Active Directory, что спасает в сильно распределенных системах.