Часто ли при разработке REST API сначала аутентифицируют пользователя?
Типичный пример использования, который я ищу:
- Пользователь хочет получить данные. Конечно круто, мы любим делиться! Получите открытый ключ API и читайте дальше!
- Пользователь хочет сохранить / обновить данные ... подождите! кто ты, ты можешь это сделать?
Я хотел бы создать его один раз и позволить, скажем, веб-приложению, приложению для Android или приложению для iPhone использовать его.
REST API кажется логичным выбором с такими требованиями
Чтобы проиллюстрировать свой вопрос, я воспользуюсь простым примером.
У меня есть элемент в базе данных с атрибутом рейтинг (целое число от 1 до 5).
Если я правильно понимаю REST, я бы реализовал запрос GET, используя язык по моему выбору, который возвращает csv, xml или json следующим образом:
http://example.com/product/getrating/{id}/
Скажем, мы выбираем JSON, который возвращаем:
{
"id": "1",
"name": "widget1",
"attributes": { "rating": {"type":"int", "value":4} }
}
Это нормально для общедоступных API. Я понимаю эту роль.
У меня масса вопросов: как совместить это с моделью безопасности? Я привык к безопасности веб-приложений, где у меня есть состояние сеанса, всегда идентифицирующее моего пользователя, поэтому я могу контролировать, что они могут делать, независимо от того, что они решат мне отправить. Насколько я понимаю, это не RESTful, поэтому в данном случае это было бы плохим решением.
Я попробую использовать другой пример с тем же предметом / рейтингом.
Если пользователь "JOE" хочет добавить оценку к элементу
Это можно сделать с помощью:
http://example.com/product/addrating/{id}/{givenRating}/
На этом этапе я хочу сохранить данные о том, что "JOE" дал продукту {id} рейтинг {givenRating}.
Вопрос: Откуда мне знать, что запрос пришел от «ДЖО», а не от «БОБ».
Кроме того, что, если бы это было для более разумных данных, таких как номер телефона пользователя?
На данный момент у меня есть:
1) Используйте встроенную функцию HTTP для аутентификации при каждом запросе, будь то простой HTTP или HTTPS.
Это означает, что теперь каждый запрос принимает форму:
https://joe:[email protected]/product/addrating/{id}/{givenRating}/
2) Используйте подход, подобный Amazon S3 с закрытым и открытым ключом: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
3) В любом случае используйте cookie и сломайте часть REST без сохранения состояния.
Мне кажется, что второй подход лучше, но я задаюсь вопросом, действительно ли мне нужно заново изобретать все это? Сам хеширую, храню, генерирую ключи и т. Д.?
Это очень похоже на использование сеанса в типичном веб-приложении и самостоятельное переписывание всего стека, что обычно для меня означает «Вы делаете это неправильно», особенно когда речь идет о безопасности.
РЕДАКТИРОВАТЬ: Думаю, мне также следовало упомянуть OAuth.
getratingиandrating; это будет простоrating, и вы должны GET, POST, PUT или DELETE к этому ресурсу. - person Duncan schedule 31.01.2013