Google Cloud Endpoints rispetto ai normali gestori di richieste per piccole applicazioni web?

Question

Sto lavorando a una piccola webapp in App Engine, utilizzando Angular per il frontend. Ho esaminato la documentazione di Google Cloud Endpoint, ma ho difficoltà a trovare vantaggi significativi rispetto alla semplice scrittura di gestori normali che restituiscono JSON. Ecco i vantaggi che ho trovato:

• API explorer: a portata di mano, ma non così importante
• Auth: utile, ma non terribilmente difficile da attuare
• librerie native: sembra meno importante per il web-only apps

D'altra parte, la sintassi per la specifica degli endpoint è un po 'brutta (rispetto alla specifica dei gestori di richieste in webapp2, flask, ecc.). Ci sono dei vantaggi che ho perso o delle sfide che non sto prevedendo? In caso contrario, qual è il punto di Cloud Endpoints?

Answer 1

Gli endpoint sono un modo comodo per i servizi utilizzati da entrambe le app Web e mobili, ma con restrizioni. Non lo consiglierò per le app solo web.

Endpoint facilita la creazione di un'unica API di pubblicazione dati per web, Android e iOS. Lo stesso può essere ottenuto definendo la propria API REST/JSON. Differenza da REST servizio/JSON sono:

Vantaggi

1. Maggiore: Genera librerie client native per Android e dispositivi iOS app nativa.

2. La conversione da e verso JSON viene eseguita senza definire alcuna mappatura.

3. Facile integrazione auth "Google" (ma 'solo' auth Google, con il supporto sperimentale OpenID)

4. API Explorer è un buon valore aggiunto per astrazione così come Interfaccia utente amministrativa (ma manca un po 'di base previsto caratteristiche, come il supporto per il parametro di tipo 'Date')

5. [ripensamento] utilizzando endpoint con accesso integrato e hosting su app-motore, la maggior parte dei problemi di sicurezza di autenticazione legati vengono scaricati su Google

Svantaggi

1. Maggiore: Nessun controllo sulla conversione JSON. Finisci per cambiare la tua struttura/codice di entità a what Endpoints can handle. per esempio. no Generics (in Java)

2. Nessun controllo sulla gestione degli errori durante la conversione. per esempio. se una chiamata di caricamento lenta incontra un problema, la conversione JSON fallisce senza fornire dettagli su ciò che si è rotto all'interno.

3. La parte del servizio di rilevamento che carica l'API per la radice API (probabilmente Google non ne ha bisogno) ha poor browser support.

4. [Modifica: Not applicable anymore] Come detto da @Josh, non è disponibile il supporto del dominio personalizzato.La soluzione alternativa consiste nell'utilizzare il dominio appengine internamente per le chiamate degli endpoint, che viene fornito con l'overhead per mantenere i mapping dei domini per tutti gli ambienti.

Answer 2

trovo la mancanza di supporto per il test automatizzato semplice rende il gestore della richiesta normale avvicinarsi una misura migliore per la mia piccola applicazione web.

Answer 3

Il punto più importante degli endpoint di Google è la possibilità di avere una soluzione scalabile anziché utilizzare la piattaforma IAAS come Amazon. Inoltre l'integrazione con google app engine.

L'API explorer più le librerie generate dal cliente sono a mio avviso solo una funzionalità "piacevole da avere" piuttosto che la ragione principale per scegliere Google Cloud Endpoint su qualsiasi semplice server SA nel cloud.

Altri vantaggi sono i metadati API che possono controllare il controllo di accesso, i client consentiti, il controllo delle versioni e la trasformazione incorporata.

La cosa bella per me era che tutto in questa piattaforma era davvero intuitivo e fatto con i comandi di Maven, inclusa la distribuzione dell'app su *. Appspot google cloud.