Аутентификация проста.
Вы можете обрабатывать сеансы как ресурсы:
POST /sessions {email, password}
-> {userId, token}
После этого вы можете отправить обратно маркер в заголовке HTTP или в куки (лучше в заголовке HTTP, потому что она защищает вас от атак CSRF). I служба не получает токен в заголовке запроса, чем может отправить обратно 401 несанкционированный ответ. Если вы не можете создать сеанс, вы можете отправить обратно 4 ** запрос, я использую для отправки обратно 404 не найден.
Разрешение более сложное.
Вы должны решить, насколько гранулирована ваша система авторизации. Это может быть ACL, RBAC, ABAC, зависит от сложности вашего приложения и ваших правил доступа. Обычно люди используют ACL и RBAC жёстко, как этот (фиктивного язык):
@xml
role 1 editor
@/articles
ArticleController
@GET/
readAll() {
if (session.notLoggedIn())
throw 403;
if (session.hasRole("editor"))
return articleModel.readAll();
else
return articleModel.readAllByUserId(session.getUserId());
}
Это прекрасно работает на более простых систем, но при таком подходе вы никогда не будете иметь чистый код, потому что контроль доступа не должен быть частью бизнес-логики , вы должны экстеризировать это. Вы можете сделать это с помощью системы ABAC, например, с помощью реализации XACML. (XACML является отличным инструментом, но я считаю, это немного сложнее). Вы можете создать пользовательскую систему автоматического ДКС с этим подходом тоже (тот же пример):
@db
role 1 editor
policy 1 read every article
constraints
endpoint GET /articles
permissions
resource
projections full, owner
role 2 regular user
policy 2 read own articles
constraints
endpoint GET /articles
logged in
permissions
resource
projections owner
@/articles
ArticleController
@GET/
readAll() {
if (session.hasProjection(full))
return articleModel.readAll();
else if (session.hasProjection(owner))
return articleModel.readAllByUserId(session.getUserId());
}
Примечание: если у вас есть несколько поставок, а не только REST (например, SOAP, веб-приложение, flash и т. д.), тогда лучше описать логику авторизации с помощью терминов домена, а не с условиями доставки, такими как URI и т. д.). – inf3rno