LD>Тогда не в порядке спора и попыток переубедить. Объясните как реализовать с помощью REST процедуру логона. Ну точнее не реализовать, а какие API (ресурсы должны быть). Типичный сценарий:
LD>1. Клиент начинает сессию (передает имя пользователя, и способ аутентификации).
LD>2. Сервер поднимает плагин, отвечающий за этот способ и отдает ему имя пользователя.
LD>3. Плагин генерит некие данные (challenge), отдает серверу, а он отдает клиенту.
LD>4. Клиент запрашивает у пользователя его секретные данные (пароль, палец и пр), отсылает серверу.
LD>5. Сервер передает эти данные плагину, который может:
LD> a. Сказать, что логон успешен.
LD> b. Сказать, что логон не успешен.
LD> с. Затребовать новые данные.
Ну, что-то в такое (писал после бессонной ночи на коленке, и вообще лучше посмотреть на OAuth, например, который что-то подобное реализует)
POST /authorization
> Authorization: SomeAuth "some-string"
> Content-Type: application/vnd.example.com-auth-v1+json
{
"login": "Bob"
}
< 401 Unauthorized
< WWW-Authenticate: SomeAuth realm="myRealm", credentials="1234567890"
POST /authorization
> Authorization: SomeAuth "some-string", credentials="1234567890"
> Content-Type: application/vnd.example.com-auth-v1+json
{
"login": "Bob",
"data": [...]
}
Логин успешен:
< 302 Temporary Redirect
< Location: /куда/нибудь
Логин неуспешен:
< 401 Unauthorized
< WWW-Authenticate: SomeAuth realm="myRealm",
credentials="0987651",
someauth_error="invalid login"
Еще данные:
Логин неуспешен:
< 401 Unauthorized
< WWW-Authenticate: SomeAuth realm="myRealm",
credentials="0987651",
someauth_error="more data needed"
LD>>>Тогда не в порядке спора и попыток переубедить. Объясните как реализовать с помощью REST процедуру логона. Ну точнее не реализовать, а какие API (ресурсы должны быть).
M>>Ну, что-то в такое (писал после бессонной ночи на коленке, и вообще лучше посмотреть на OAuth, например, который что-то подобное реализует)
D>Чёт я недопонял, зачем в REST API отдельная точка входа для login.
При желании можно сделать (для реализации OpenID/OAuth, например, отдельная точка входа все равно будет). Отдельная точка входа REST'у не противоречит
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>У меня статья есть на эту тему, вдруг пригодится: http://gandjustas.blogspot.ru/2013/02/aspnet-mvc.html
S>Отличная статья. Если я правильно понимаю, то подразумеваемый способ борьбы с conditional Get всё же другой.
S>У тебя идёт ручное управление кэшированием: ты кладёшь ответ в кэш вручную, и вручную же проверяешь, что там не так.
S>В теории, вся семантика последующей работы с кэшем уже реализована в самом ASP.NET.
S>То есть, достаточно выставить респонсу подходящий cacheability, зарегистрировать зависимости в response.AddCacheDependency() (например, зависимость от результата SQL-запроса), и всё будет работать само.
S>Логика — примерно такая: если приходит запрос на URL, который уже есть в кэше ASP.NET, то кэш его проверяет на предмет валидности, дёргая HasChanged у всех депенденсей, и если всё в порядке, то отдаёт ответ из кэша, не вызывая код контроллера. А если в запросе присутствует If-Modified-Since, то он ещё и отдаёт 304 вместо контента.
S>К сожалению, на практике я так и не дошёл до полной реализации этого подхода. Если нет подводных камней, то код твоего метода CartSummary должен сократиться в разы.
Таки написал статью по этому
http://habrahabr.ru/post/227129/
