2

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

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

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

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

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

+1

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

ответ

1

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

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

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

+0

API-интерфейс конечных точек Proto Datastore выглядит точно так же, как я имел в виду делать дальше. Мне нужно будет поиграть и посмотреть, предпочитаю ли я определять свои классы сообщений ProtoRPC в пользу API, но в любом случае это должно делать именно то, что я хочу. И это приятно знать, что это достойный подход к тому, что я пытаюсь сделать. – LulzCow