Использование конечных точек App Engine Cloud для доступа к хранилищу данных ndb

Прошу прощения, если этот вопрос является избыточным или плохо продуманным, но я новичок в App Engine и не уверен в лучших практиках того, что я пытаюсь сделать.

У меня есть приложение для iOS, и я хочу использовать HTTP-запросы GET и POST для размещения и запроса в моем хранилище данных ndb.

Пока мой API конечных точек работает с жестко закодированными данными, и я могу успешно выполнить GET и POST в своем приложении и увидеть результаты. Теперь мне нужно сделать то же самое, но с результатами из хранилища данных. Я использую структуру webapp2 для использования ndb.

Итак, мой вопрос в основном таков: это оптимальный способ хранения и получения данных для моего приложения? Запросы, которые мне нужны, несложны, но в моем хранилище данных будет огромное количество операций чтения / записи. Этот вопрос может показаться глупым, но я просто прошу убедиться, что я не совершаю огромной ошибки в своем дизайне, или, по крайней мере, убедиться, что нет лучшего способа добиться этого.

Итак, вкратце: я использую API конечных точек для доступа к хранилищу данных nbd для мобильного приложения. Это правильно? Если да, то каковы лучшие практики?


comment
Это именно то, для чего он нужен. Вам не нужен настоящий API для жестко закодированных данных, вы можете просто обслуживать статические файлы JSON. Вся суть API с чем-то вроде конечных точек заключается в том, что он обслуживает динамические данные из вашего хранилища данных.   -  person Daniel Roseman    schedule 13.05.2015


Ответы (1)


Да, это вполне разумный подход.

Если вы используете Cloud Endpoints и NDB, вам может потребоваться Endpoints Proto Datastore API который упрощает сериализацию сущностей модели NDB.

Лично мне API не показался интуитивно понятным, поэтому я вернулся к созданию собственного ProtoRPC Классы сообщений (которые сильно отличаются от подхода Java к конечным точкам облака).

person tx802    schedule 13.05.2015
comment
API хранилища данных Endpoints Proto выглядит в точности так, как я задумал сделать дальше. Мне придется поиграть и посмотреть, предпочитаю ли я определять свои классы сообщений ProtoRPC в пользу API, но в любом случае это должно делать именно то, что я хочу. И приятно осознавать, что это достойный подход к тому, что я пытаюсь сделать. - person LulzCow; 13.05.2015