тестирование конечных точек движка приложения на локальном хосте (IOS и Python)

Мои конечные точки работают через API-Explorer, а также работают в среде выполнения движка приложения (через сеть)

Но когда я указываю своему клиенту IOS (через симулятор) на localhost: 8080, мои тесты IOS терпят неудачу, и я вижу, что в конечную точку прибывают пустые полезные данные сообщения (на стороне Python).

Это довольно неприятно, и я пытался понять это несколько дней ...

Я зашел в исходный код protorpc, добавил распечатку и получил следующее:

{
  "jsonrpc": "2.0",
  "method": "tstone.person.createGuy",
  "id": "gtl_1",
  "params": {
    "resource": {
      "isFemale": false,
      "alias": "Alias",
      "city": "Hanoi",
      "id": "1",
      "mobile": "+84932340799",
      "privs": "privs",
      "email": "hodanhcXXXgmail.com",
      "last": "Danh Chuan",
      "first": "Ho",
      "tags": "tags"
    }
  },
  "apiVersion": "v1"
}

Итак, ясно, что мои данные поступают от клиента IOS, но где-то в смеси они теряются, так что нет данных о свойствах сообщения "запрос", которое достигает моего кода ......_ 2_ Я также вижу это предупреждение в консоли сервера:

protojson.py:267] No variant found for unrecognized field: resource

Переполнение стека означает, что "вариантная" ошибка была обычным явлением (на локальном хосте) в версии сервера разработки более 1,5 года назад ... и я использую (последнюю) версию:

• приложение-двигатель-Python 1.9.34
• ядро 2016.03.22

Поскольку он работает в указанных выше средах (API-Explorer / среда выполнения приложения-движка), я предполагаю, что это не проблема с моим кодом, а проблема с моей установкой или локальной конфигурацией.

Итак, я начал просматривать модули в моем каталоге vendored / lib, чтобы увидеть, были ли какие-то старые версии или конфликты с чем-то в модулях dev_appserver ....

Я нашел несколько таких, которых, как я подозреваю, НЕ ДОЛЖНО быть ... Похоже, что движок приложения уже должен иметь многие из них на своем собственном пути:

• апиклиент
• googleapiclient
• httplib2
• oauth2
• oauth2client (используется инструментарием идентификации, так что с этим, вероятно, все в порядке)
• protopigeon (Депутат Ferris3, так что я думаю, это тоже нормально)
• пясн1
• pyasn1_modules
• RSA
• simpleauth (я также использую это для инструментария идентификации, так что все в порядке)
• simplejson
• шесть
• wsgiproxy

Кроме того, на странице установки Ferris я обнаружил следующее:

Если вы начинаете с нуля и используете webapp2 или просто используете Cloud Endpoints: используйте проект Skeleton

Итак, если мы НЕ используем webapp2, нам разрешено делать простые pip install ferris, но если мы используем конечные точки или webapp2, мы должны пройти через какой-то сложный процесс через Node, Yeoman и генератор Ferris ...

Почему дополнительная сложность ..... может кто-нибудь объяснить мне это?

И спасибо за любые советы !! Дьюи