在本地主机上测试App Engine端点（IOS和Python）

Question

My endpoints work via API-Explorer, and also work in the app-engine runtime environment (over the net)

But when I point my IOS client (via the simulator) to localhost:8080, my IOS tests fail and I'm seeing empty message payloads arriving at the endpoint (on the python side)

It's quite frustrating and I've been trying to figure it out for several days.....

I went into the protorpc source and added a print and get this:

{
  "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"
}

So it's clear my data is arriving from the IOS client, but somewhere in the mix it's getting lost so that there is no data on the properties of the "request" message that reaches my code...... all == None I also see this warning in the server console:

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

Stack overflow implies that "variant " error was common (on localhost) in a version of the dev server over 1.5 years ago......and I'm on (the latest) version:

• app-engine-python 1.9.34
• core 2016.03.22

Since it works in the above (API-Explorer/app-engine runtime) environments, I surmise that it's not a problem with my code and instead an issue with my install or local config

So I started looking through the modules in my vendored /lib directory to see if any were old versions or conflicting with something in the dev_appserver modules....

I found several that I suspect should NOT be there..... It seems like app engine should already have many of these in it's own path:

• apiclient
• googleapiclient
• httplib2
• oauth2
• oauth2client (used by identity toolkit so this one is probably ok)
• protopigeon (a dep of ferris3 so I guess this is ok too)
• pyasn1
• pyasn1_modules
• rsa
• simpleauth (I'm also using this for identity toolkit so its ok)
• simplejson
• six
• wsgiproxy

Furthermore, on the Ferris install page, I found this:

If you're starting from scratch and you're using webapp2 or just using Cloud Endpoints: use the Skeleton project

So if we are NOT using webapp2, we're allowed to do a simple pip install ferris , but if we ARE using endpoints or webapp2, we must go through some complex process via Node, Yeoman, and Ferris generator.....

Why the added complexity.....can someone please explain this to me?

And thanks for any tips!! Dewey

Answer 1

1. Regarding the Ferris 3 project, there's the option to use the ferris 3 generator to help you with a simple predefined app showing a simplified structure of how to get started with the project. Since it's a yeoman generator, you'll need nodejs , yeoman, etc...

   But all of that is optional . Nothing complex. They're just there as an option to jump start into bigger stuff, handling a bit of boilerplate :)

2. Ferris depends on the google-api-python-client which in turn needs all those dependencies.

   True, these dependencies seem to come as part of the app engine & google cloud sdk's lib & third party lib folders respectively so I guess they can be added in the app.yaml 's libraries section. But it's difficult tracking down versions from there, and from prior experience I can say with some degree of certainty that you wouldn't want to depend on those in production. They're not pinned and thus change all the time. For a list of absolutely supported libs you can check out https://cloud.google.com/appengine/docs/python/tools/libraries27

   I've always vendored the google-api-python-client as advised @ https://developers.google.com/api-client-library/python/start/installation#appengine So what you have now is correct.

3. Last but not least, like you rightly point out, the error you're seeing seems to have existed for quite some time. Dave Fisher provides a workaround for the unrecognized field: 'resource' error in his answer from a few years back which has proved helpful.

Answer 2

BTW this issue is fixed on the latest version of the Google API Objective-C client library. Time to port everything to GTLR. Yeah! :)

https://github.com/google/google-api-objectivec-client-for-rest

Other docs for GTLR stuff: https://github.com/google/google-api-objectivec-client-for-rest/wiki http://cocoadocs.org/docsets/GoogleAPIClientForREST

Warning we hit a bug using that library were we had to replace some of the library generated #import lines. I forget the details, but it was an easy edit. I just hate modifying generated code.

The real pain is all the other little changes to do the port. ;) It is a better system and a good port to do though.