2016-03-22 3 views
0

Я только что начал в Google Cloud, и я создаю приложение iOS для взаимодействия с облачными сервисами Google через мобильный сервер. Я использую Python для написания бэкэнда для App Engine. Я прошел учебники по созданию API на основе конечных точек, но у меня есть вопрос.Cloud Endpoints and App Engine

Должен ли я создать API конечных точек Cloud, а затем приложение в App Engine? В принципе, я хочу иметь возможность регистрировать учетные записи в своем приложении iOS, вызывать API, который затем использует Хранилище данных Google для хранения данных учетной записи. От взгляда на учебные пособия (как конечные точки облака, так и гостевая книга), я собираюсь выставить хранилище данных Google, облачное хранилище и т. Д. В пределах конечных точек api? Или это ссылка на другое приложение, где все это сделано?

Извините, если это звучит немного глупо, но я просто хочу убедиться!

Заранее спасибо.

ответ

0

Вкратце, ваш API конечных точек Cloud является вашей заявкой. Некоторые из документации относительно Cloud Endpoints могут быть немного запутанными (или неопределенными), но на стороне сервера это, по сути, куча декораторов Python или аннотаций Java, которые позволяют вам разоблачить вашу прикладную логику как REST API.

Я нахожу реализацию Java Cloud Endpoint более интуитивно понятной, чем Python, что требует немного больше работы для (дезафигурации) ваших объектов. Вы можете посмотреть на endpoints_proto_datastore.ndb.EndpointsModel, который может вывести часть содержимого шаблона из уравнения (определяя сообщения).

По существу, когда вы пишете свой API, каждая конечная точка переходит к функции python. Внутри этой функции вы можете делать то, что вам нравится, но, как правило, это будет либо:

  1. Deserialise Опубликованная JSON, проверить его, и написать некоторые объекты в хранилище данных (или Cloud SQL, BigTable, везде).

  2. Прочитайте одно или несколько объектов из хранилища данных и сериализуйте их в JSON и верните их клиенту.

Например, вы можете определить свой API (весь набор функций конечной точки) в качестве

@endpoints.api(name='cafeApi', version='v1', description='Cafe API', audiences=[endpoints.API_EXPLORER_CLIENT_ID]) 
class CafeApi(remote.Service): 
    # endpoints here 

Например, вы могли бы иметь конечную точку, чтобы получить близлежащие кафе:

@endpoints.method(GEO_RESOURCE, CafeListResponse, path='cafes/nearby', http_method='GET', name='cafes.nearby') 
def get_nearby_cafes(self, request): 
    """Get cafes close to specified lat,long""" 
    cafes = list() 
    for c in search.get_nearby_cafes(request.lat, request.lon): 
     cafes.append(c.response_message()) 

    return CafeListResponse(cafes=cafes) 

Несколько вещей, чтобы выделить здесь. С реализацией Python Endpoints вам необходимо определить свои классы ресурсов и сообщений - они используются для инкапсуляции данных запроса и органов ответа.

Так, в приведенном выше примере, GEO_RESOURCE инкапсулирует поля, необходимые, чтобы сделать GeoPoint (таким образом мы можем искать по местоположению с помощью Search API, но вы можете просто искать Datastore для кафе с рейтингом 5 зв):

GEO_RESOURCE = endpoints.ResourceContainer(
     message_types.VoidMessage, 
     lat=messages.FloatField(1, required=True), 
     lon=messages.FloatField(2, required=True) 
    ) 

и CafeListResponse просто инкапсулировать list объектов CafeResponse (с Cloud Endpoints вы возвращаетесь один объект):

class CafeListResponse(messages.Message): 
    locations = messages.MessageField(CafeResponse, 1, required=False, repeated=True) 

CafeResponse, где это сообщение, которое определяет, как вы хотите, чтобы ваши объекты (как правило, объекты Datastore) были сериализованы вашим API. например,

class LocationResponse(messages.Message): 
    id = messages.StringField(1, required=False) 
    coordinates = messages.MessageField(GeoMessage, 3, required=True) 
    name = messages.StringField(4, required=False) 

С этой конечной сигнатуры, вы можете получить доступ к нему через HTTP GET в /cafeApi/v1/cafes/nearby?lat=...&lon=... или с помощью, скажем, клиент JavaScript API с помощью `cafeApi.cafes.nearby (...).

Лично я нашел Flask немного более гибким, работая с Python, чтобы создать REST API.

+0

Hi @ tx802, спасибо большое за этот подробный анализ! Я знаю Java больше, чем Python, но я был поражен тем, как на Python существует больше репозиториев, чем на Java (что указывает на немного большую поддержку/популярность), хотя я считаю последнее немного более интуитивным. Есть ли преимущество в использовании любого из двух? – neX

+0

Это, безусловно, помогло - я думаю, я понимаю, какие конечные точки облака теперь предназначены! – neX

Смежные вопросы