OpenID существует для того, чтобы приложения могли использовать крупную, устоявшуюся сущность, такую как Google, для обработки аутентификации пользователей, чтобы разработчик приложений мог сосредоточиться на других задачах. Ваша цель, основанная на вашем вопросе, состоит в том, чтобы сделать именно это, перегрузить проблемы хранения данных третьей стороне, чтобы вы могли сосредоточиться на вашем продукте и избежать повторного изобретения колеса.
Однако OpenID не работает так. Идея, как вы знаете, заключается в том, чтобы передать процесс аутентификации и только процесс аутентификации третьей стороне. OpenID должен делать не больше, не меньше; он либо отвечает «да, мы знаем, что этот человек является тем, кем он / она говорит, что он / она», либо «нет, я не знаю этого человека».
Хранение данных приложения в учетной записи Google было бы своего рода побеждать цель OpenID, и я не вижу ни одного поставщика OpenID, нарушающего этот стандарт.
Решения вашей проблемы:
С учетом сказанного, у меня есть два решения, чтобы предложить вам, что, хотя они не являются точно тем, что вы ищете, они действительно решают вашу проблему и позволит вам сосредоточиться на создании вашего продукта и вашего бренда.
Bigtable-JS:
Bigtable-JS - проект, поддерживаемый Крисом Тэтчером. Это RESTful JSON база данных, которая работает на Google App Engine. Вам не нужно знать Python или Java для работы с ним, поскольку он предназначен для приема запросов HTTP GET, POST, PUT и DELETE для простого извлечения и хранения данных в хранилище данных Google App Engine с высокой степенью масштабируемости.
Проект не обновлялся в течение 2 лет, но, учитывая, что он просто хранит строки JSON, вполне возможно, что обслуживание будет минимальным.
Кроме того, поскольку ваши потребности в хранении данных невелики, при достаточном объеме кэширования вполне возможно, что вы сможете работать, не превышая бесплатных квот Google App Engine.
Этот проект с открытым исходным кодом доступен на GitHub .
Blogger
Можно ли сказать, что когда большинство людей думает о Google Blogger , они думают о блогах? Ну, Бретт Морган и Пэт Колеман, оба из команды Google Blogger, похоже, думают иначе.
В своей 42-минутной презентации на конференции Google IO 2011 года под названием Google I / O 2011: создание веб-сайтов для бизнеса с помощью API Blogger они рассказывают, как они используют API Blogger для создания сайтов электронной коммерции и мобильных веб-сайтов. использование инфраструктуры Google и использование проверенных и проверенных API.
Веб-сайты, которые они показывают в своих демонстрациях, не похожи на Blogger, и это потому, что они смотрели дальше блогов и вместо этого использовали более абстрактный подход к использованию API:
- Сообщения
- Заголовок сообщения
- Автор сообщения
- Дата публикации
- Почтовое тело
- Метки сообщения
- Комментарии к сообщению
Это на самом деле просто группировка под капотом, и вашему приложению не нужно заботиться о том, хранит ли оно данные в теле сообщения или в другом текстовом варианте. Сила REST заключается в том, что интерфейс между двумя системами обеспечивает многоуровневую структуру, которая освобождает их от необходимости выполнять то, что у них получается лучше всего.
Поскольку вы просто храните строку JSON, вы можете хранить эту строку в теле сообщения с помощью API Blogger и сделать блог приватным, чтобы данные были надежно защищены в инфраструктуре Google.
Резюме:
Хотя ни одно из этих решений не позволит вам хранить данные в учетной записи Google пользователя, оба из них предоставляют вам свободу сосредоточить усилия по разработке на других задачах и оставить задачи администрирования базы данных в облаке.
Другие решения, которые вы можете рассмотреть, следующие:
Redis - база данных NoSQL с открытым исходным кодом.
Хранилище Google для разработчиков - Храните данные об инфраструктуре Google с помощью интерфейса REST.Это платный сервис, но он, вероятно, ближе всего к тому, что вы ищете, поскольку он входит в консоль Google API .