Ich arbeite an einer kleinen Webanwendung in App Engine und verwende Angular für das Frontend. Ich habe die Dokumentation für Google Cloud Endpoints gelesen, aber es fällt mir schwer, wesentliche Vorteile gegenüber dem Schreiben normaler Handler zu finden, die JSON zurückgeben. Hier sind die Vorteile, die ich gefunden habe:
Andererseits ist die Syntax zum Angeben von Endpunkten etwas hässlich (im Vergleich zum Angeben von Anforderungshandlern in webapp2, flask usw.). Gibt es irgendwelche Vorteile, die ich verpasst habe, oder Herausforderungen, die ich nicht vorhersage? Wenn nicht, wozu Cloud Endpoints?
Endpoints ist eine bequeme Möglichkeit für Dienste, die sowohl von Web- als auch von mobilen Apps verwendet werden, jedoch mit Einschränkungen. Ich werde es nicht für reine Web-Apps empfehlen.
Endpoints ermöglicht die Erstellung einer einzelnen Datenbereitstellungs-API für Web, Android und iOS. Dasselbe kann erreicht werden, indem Sie Ihre eigene REST / JSON API definieren. Unterschiede zum REST / JSON-Dienst sind:
Vorteile
Wichtig: Es generiert native Client-Bibliotheken für die native App für Android- und iOS-Geräte.
Die Konvertierung von und nach JSON erfolgt ohne Definition von Zuordnungen.
Einfache "Google" -Authentifizierung (aber "nur" Google-Authentifizierung, mit experimenteller OpenID-Unterstützung)
Der API-Explorer ist ein guter Mehrwert für die Abstraction- und Admin-Benutzeroberfläche (es fehlen jedoch einige grundlegende Funktionen wie die Unterstützung für den Parameter "Date")
[nachher] Durch die Verwendung von Endpunkten mit integriertem Login und Hosting auf der app-engine werden die meisten sicherheitsrelevanten Probleme in Google ausgelagert.
Nachteile
Major: Keine Kontrolle über die JSON-Konvertierung. Sie ändern Ihre Entitätsstruktur / den Code schließlich in , was Endpoints verarbeiten können . z.B. keine Generics (in Java)
Keine Kontrolle über die Fehlerbehandlung während der Konvertierung. z.B. Wenn ein Lazy Loading-Aufruf auf ein Problem stößt, schlägt die JSON-Konvertierung fehl, ohne Details darüber anzugeben, was darin enthalten ist.
Discovery-Service-Teil, der die API für Ihren API-Root lädt (Google benötigt ihn wahrscheinlich nicht), hat schlechte Browser-Unterstützung .
[Bearbeiten: Nicht mehr zutreffend ] Wie von @Josh erwähnt, gibt es keine benutzerdefinierte Domänenunterstützung . Problemumgehung besteht darin, die Appengine-Domäne intern für Endpoints-Aufrufe zu verwenden, was mit Overhead verbunden ist, um Domänenzuordnungen für alle Umgebungen zu verwalten.
Der wichtigste Punkt von Google Endpoints ist die Möglichkeit, eine skalierbare Lösung zu verwenden, anstatt die IAAS-Plattform als Amazon zu verwenden. Außerdem die Integration mit Google App Engine.
Der API-Explorer und die Client-generierten Bibliotheken sind meiner Meinung nach nur eine "nice to have" -Funktion und nicht der Hauptgrund, sich für Google Cloud Endpoints auf einem einfachen SA-Server in der Cloud zu entscheiden.
Weitere Vorteile sind die API-Metadaten, mit denen die Zugriffssteuerung, die zulässigen Clients, die Versionierung und die integrierte Umwandlung gesteuert werden können.
Das Schöne für mich war, dass alles auf dieser Plattform wirklich intuitiv war und mit Maven-Befehlen erledigt wurde, einschließlich der Bereitstellung der App in der * .appspot google cloud.
Ich finde, dass die mangelnde Unterstützung für einfaches automatisiertes Testen dazu führt, dass der normale Anfragebearbeiter besser zu meiner kleinen Web-App passt.
Tags und Links google-app-engine google-cloud-endpoints