9

I'm working on a small webapp in App Engine, using Angular for the frontend. I've looked through the documentation for Google Cloud Endpoints, but I'm having a hard time finding significant advantages over just writing normal handlers that return JSON. Here are the advantages I've found:

  • API explorer: handy, but not that important
  • Auth: useful, but not terribly difficult to implement
  • Native libraries: seems less important for web-only apps

On the other hand, the syntax for specifying endpoints is kind of ugly (compared to specifying request handlers in webapp2, flask, etc.). Are there any advantages I've missed or challenges I'm not predicting? If not, what's the point of Cloud Endpoints?

Ashish Awasthi
  • 1,302
  • 11
  • 23
whereswalden
  • 4,819
  • 3
  • 27
  • 41

3 Answers3

17

Endpoints is a convenience way for services used by both, web and mobile apps, but with restrictions. I will not recommend it for web-only apps.

Endpoints facilitates creating a single data serving API for web, Android and iOS. Same can be achieved by defining your own REST/JSON API. Difference from REST/JSON service are:

Advantages

  1. Major: It generates native client libraries for Android and iOS devices native app.

  2. Conversion to and from JSON is done without defining any mappings.

  3. Easy "Google" auth integration (but 'only' Google auth, with experimental OpenID support)

  4. API explorer is a good value-add for Abstraction as well as Admin UI (but lacks some basic expected features, like support for 'Date' type parameter)

  5. [afterthought] By using Endpoints with integrated login and hosting on app-engine, most of authentication related security concerns are offloaded to Google

Disadvantages

  1. Major: No control over JSON conversion. You end up changing your entity structure/code to what Endpoints can handle. e.g. no Generics (in Java)

  2. No control over error handling during the conversion. e.g. if a lazy loading call encounters a problem, then JSON conversion fails without giving details of what broke inside.

  3. Discovery service part that loads API for your API-root (Google probably doesn't need it) has poor browser support.

  4. [Edit: Not applicable anymore] As @Josh mentioned, there is no custom domain support. Workaround is to use appengine domain internally for endpoints calls, which comes with overhead to maintain domain mappings for all environments.

Community
  • 1
  • 1
Ashish Awasthi
  • 1,302
  • 11
  • 23
  • Another **disadvantage** is that you cannot run endpoints on a custom domain, only the appspot.com domain. – Josh J Jul 13 '15 at 20:05
2

The most important point of google endpoints is the ability to have scalable solution rather than using IAAS platform as Amazon. Moreover the integration with google app engine .

The API explorer plus the client generated libs are to my mind only a "nice to have" feature rather than the main reason to choose Google Cloud Endpoints over any simple SA server in the cloud.

Other advantages are the API metadata that can control access control , clients allowed , versioning , and built in transformation.

The nice thing for me was that everything in this platform was really intuitive and done with maven commands , including deploying the app to the *.appspot google cloud.

Yossi
  • 49
  • 1
  • 5
1

I find the lack of support for straightforward automated testing makes the normal request handler approach a better fit for my small web app.

Waterloo Stu
  • 93
  • 1
  • 7