Ответ 1
Мы остановились на следующем, используя OAuth 2 (что намного предпочтительнее OAuth 1). В частности, мы используем учетные данные пароля владельца ресурса. Что касается того, как интегрировать его в нашу службу RESTful, вот идея:
- Исходный ресурс при ударе неавторизованным пользователем возвращает 401. Тело 401 содержит одну ссылку,
rel=oauth2-token. (Как вы сигнализируете ссылки, зависит от вашего типа носителя, мы используем HAL, но вы можете использовать даже заголовокLink. ) - После аутентификации пользователя он возвращается к исходному ресурсу, отправив в свой заголовок
Authorizationтокен-носитель, возвращенный из процесса OAuth 2. На этом этапе мы возвращаем 200, со всеми доступными нормальными ссылками.
Мы не создаем создание учетной записи, но если вы захотите это сделать, я сделаю это с другой ссылкой, доступной для неавторизованных пользователей в исходном ресурсе. Эта ссылка будет иметь пользовательский rel, поскольку она специфична для вашего приложения, например. rel=http://rels.myapi.com/users
Хороший дизайн RESTful указывает, что ссылка с этим rel указывает на, например, http://myapi.com/users, и что потребители API делают POST к этой конечной точке, которая возвращает им новый пользовательский ресурс с заголовком Location, указывающим на вновь созданный пользовательский ресурс, например, http://myapi.com/users/username. (Разумеется, сами пользовательские ресурсы были бы еще одним rel, что отличает уникальный ресурс пользователя и ресурс коллекции множественных пользователей.)