> откаменчу, что до этого мы предполагали, что сам ресурс, вокруг которых весь REST
> крутится, НЕ ИЗМЕНЯЕТСЯ пока мы там аутентифицируемся или еще что-то
Т. е. блокируется что ли? А если у нас хайлоад какой-нибудь? Неее, не складывается что-то.
1) Ну смотрите:
Я делаю GET somehost/someresource/100500
Далее кто-то делает POST somehost/someresource/100500 и изменяет ресурс который лежит по данному uri.
Когда я сделают такой же GET somehost/someresource/100500 я получу уже совсем другой результат. Это же не значит, что сервис уже не RESТ? А все потому что изменилось не состояние сервиса, а состояние некоего внешнего по отношению к сервису ресурса.
А поведение осталось то же — берем ресурс из БД, сериализуем и возвращаем пользователю.
А вот пример сервиса с воркфлоу: например у меня есть некий документооборот и я хочу создать некий ресурс-запись и привязать к нему некий набор файлов. С воркфлоу-сервисом возможен следующий вариант:
1. Я вызываю у сервиса некий метод «Создай мне ресурс», сервис его создает и запоминает состояние для моей сессии, что я только что просил у него создать ресурс и запоминает например некий внутренний идентификатор.
2. Несколькими последовательными запросами я заливаю файлы, причем сервис привязывает их к той записи, которую только что для меня создал.
Сценарий для типичной веб-разработки странный, но довольно-таки часто встречается в энтерпрайзном документообороте, что и породило разнообразные state machine движки.
Обратите внимание, что сервис по сути поменял интерфейс между шагом 1 и 2, как и положено конечному автомату.
2) Простой пример — токен может сразу нести в себе информацию о том, какими правами обладает пользователь или к какому множеству данных он может получить доступ, что позволяет их проверить без лишних запросов к той же БД. Так например работает Active Directory, что спасает в сильно распределенных системах.
1. БД — это внешний ресурс, и состояние БД — это не есть состояние самого сервиса.
Сервисы с состоянием — это например сервисы в виде конечных автоматов (workflow services), которые ожидают вызовов от пользователя в строго определенном порядке и в зависимости от передаваемых данных
Вопрос не в реализации, а в семантике. Если есть стандартизованный хидер, предназначенный специально для авторизационных токенов, то токены там и должны лежать в большинстве случаев.
То есть — если я увижу незнакомый сервис, то я буду с большей вероятностью ждать, что токен лежит именно в хидере авторизации, потому что это ближе к стандарту, соответственно поддержка сервиса для меня будет чуточку дешевле.
Давайте определимся все-таки. Есть аутентификация — выдача пользователю некоего токена-пропуска, на основе его логина и пароля.
Авторизация — определение пользователя на основе токена и обеспечение доступа к некоторым запрошенным ресурсам.
Отличается это тем, что токен может нести в себе некоторые дополнительные данные, которые можно проверить и по которым можно определеить пользователя БЕЗ обращения к каким-либо базам данных.
Еще один плюс — у вам может быть несколько механизмов аутентификации (своя БД, аутентификация через всякие openauth, внешние сервисы и тому подобное), но единая авторизация за счет единого авторизационного токена. Ну или единый сервис аутентификации, который выдает токен и набор разных сервисов, которые этот токен принимают.
Противоречие здесь не в EventCollection, а в том, что по сути не определен интерфейс самого обработчика события. Что приводит к этим самым проверкам на тип возвращаемого значения, для того чтобы понять какой все-таки хэндлер запустился.
Как правило, обработчики событий оперируют некими дескрипторами событий с определенным интерфейсом, в том числе в некоторых есть флаги остановки запуска следующих обработчиков.
По сути этот флаг здесь реализован через вызов функции stopPropagation(), но все равно, как-то оно все смущает.
Смотрите: пусть есть некоторый класс A с каким-либо интерфейсом. И в это понятие интерфейса входит некий набор публичных методов и полей, некоторый набор исключений, которые могут бросаться этими методами. Иногда даже некие сайд-эффекты (хотя это плохо, но бывает всякий легаси, который нужно поддерживать в процессе рефакторинга).
Теперь вы наследуете от класса A некий класс B, который каким-либо образом переопределяет поведение класса А. Так вот, LSP говорит нам о том, что мы должны реализовать класс B таким образом, чтобы он полностью сохранил внешний интерфейс класса А, и что некий внешний код, который использует эти классы ничего не должен знать о разнице между классами A и B.
И все это вместе позволяет писать код, поведение которого можно расширять не изменяя данный код, а просто расширяя (наследуя) существующие классы и внедряя объекты в нужные места, например с помощью DI-контейнеров.
Пример:
Вы пишете некий юнит-тест, который тестирует класс A, который в свою очередь зависит от некоего класса B. Для того чтобы тест был именно модульный, вы должны заменить класс B неким «фальшивым» классом MockB с таким же интерфейсом как и у класса B. Соответственно, класс A должен быть написан таким образом, чтобы он не видел разницы между B и MockB.
> крутится, НЕ ИЗМЕНЯЕТСЯ пока мы там аутентифицируемся или еще что-то
Т. е. блокируется что ли? А если у нас хайлоад какой-нибудь? Неее, не складывается что-то.
За многословность прошу прощения, не сразу понял в чем у вас недопонимание.
Я делаю GET somehost/someresource/100500
Далее кто-то делает POST somehost/someresource/100500 и изменяет ресурс который лежит по данному uri.
Когда я сделают такой же GET somehost/someresource/100500 я получу уже совсем другой результат. Это же не значит, что сервис уже не RESТ? А все потому что изменилось не состояние сервиса, а состояние некоего внешнего по отношению к сервису ресурса.
А поведение осталось то же — берем ресурс из БД, сериализуем и возвращаем пользователю.
А вот пример сервиса с воркфлоу: например у меня есть некий документооборот и я хочу создать некий ресурс-запись и привязать к нему некий набор файлов. С воркфлоу-сервисом возможен следующий вариант:
1. Я вызываю у сервиса некий метод «Создай мне ресурс», сервис его создает и запоминает состояние для моей сессии, что я только что просил у него создать ресурс и запоминает например некий внутренний идентификатор.
2. Несколькими последовательными запросами я заливаю файлы, причем сервис привязывает их к той записи, которую только что для меня создал.
Сценарий для типичной веб-разработки странный, но довольно-таки часто встречается в энтерпрайзном документообороте, что и породило разнообразные state machine движки.
Обратите внимание, что сервис по сути поменял интерфейс между шагом 1 и 2, как и положено конечному автомату.
2) Простой пример — токен может сразу нести в себе информацию о том, какими правами обладает пользователь или к какому множеству данных он может получить доступ, что позволяет их проверить без лишних запросов к той же БД. Так например работает Active Directory, что спасает в сильно распределенных системах.
То что вы называете семантикой — это не семантика (смысловое значение, грубо говоря), а описание процесса.
Хидер Authorization введен специально для авторизации (RFC 2617).
Cookie — это механизм хранения информации о состоянии сессии (RFC 6265).
Лично мне разница очевидна.
Сервисы с состоянием — это например сервисы в виде конечных автоматов (workflow services), которые ожидают вызовов от пользователя в строго определенном порядке и в зависимости от передаваемых данных
msdn.microsoft.com/en-us/magazine/cc164251.aspx
2. Есть целый стандартизованный формат для токенов (правда больше для soap) — en.wikipedia.org/wiki/Security_Assertion_Markup_Language
Соответственно, и примеры там есть ;)
То есть — если я увижу незнакомый сервис, то я буду с большей вероятностью ждать, что токен лежит именно в хидере авторизации, потому что это ближе к стандарту, соответственно поддержка сервиса для меня будет чуточку дешевле.
Авторизация — определение пользователя на основе токена и обеспечение доступа к некоторым запрошенным ресурсам.
Отличается это тем, что токен может нести в себе некоторые дополнительные данные, которые можно проверить и по которым можно определеить пользователя БЕЗ обращения к каким-либо базам данных.
Еще один плюс — у вам может быть несколько механизмов аутентификации (своя БД, аутентификация через всякие openauth, внешние сервисы и тому подобное), но единая авторизация за счет единого авторизационного токена. Ну или единый сервис аутентификации, который выдает токен и набор разных сервисов, которые этот токен принимают.
Правда?
Например — www.opennet.ru/base/sec/ssl_cert.txt.html
>> Cookies нарушает принцип Stateless — серверу надо хранить связь этого Cookies с конкретным пользователям.
Совсем необязательно, куки (а точнее авторизационный токен) уже может нести в себе всю информацию о сессии и пользователе.
Как правило, обработчики событий оперируют некими дескрипторами событий с определенным интерфейсом, в том числе в некоторых есть флаги остановки запуска следующих обработчиков.
По сути этот флаг здесь реализован через вызов функции stopPropagation(), но все равно, как-то оно все смущает.
Смотрите: пусть есть некоторый класс A с каким-либо интерфейсом. И в это понятие интерфейса входит некий набор публичных методов и полей, некоторый набор исключений, которые могут бросаться этими методами. Иногда даже некие сайд-эффекты (хотя это плохо, но бывает всякий легаси, который нужно поддерживать в процессе рефакторинга).
Теперь вы наследуете от класса A некий класс B, который каким-либо образом переопределяет поведение класса А. Так вот, LSP говорит нам о том, что мы должны реализовать класс B таким образом, чтобы он полностью сохранил внешний интерфейс класса А, и что некий внешний код, который использует эти классы ничего не должен знать о разнице между классами A и B.
И все это вместе позволяет писать код, поведение которого можно расширять не изменяя данный код, а просто расширяя (наследуя) существующие классы и внедряя объекты в нужные места, например с помощью DI-контейнеров.
Пример:
Вы пишете некий юнит-тест, который тестирует класс A, который в свою очередь зависит от некоего класса B. Для того чтобы тест был именно модульный, вы должны заменить класс B неким «фальшивым» классом MockB с таким же интерфейсом как и у класса B. Соответственно, класс A должен быть написан таким образом, чтобы он не видел разницы между B и MockB.
> return ($r instanceof SomeResultClass);
> });
А вот здесь LSP и нарушается.