Questa è una domanda interessante e non molto facile da rispondere. Dipende da quale sito web stai sviluppando, per giustificare lo sforzo in qualsiasi direzione. Ecco la mia opinione per alcuni dei tuoi punti:
Utilizzo dell'API per tutto: Svantaggi
- Lots of HTTP requests to the API
Dipende se stai sviluppando un sito web standard o uno che dovrebbe essere accessibile in modo esteso tramite dispositivi mobili. Ha senso usare porzioni più piccole, ma comunicazioni più frequenti nel caso in cui il client sia un dispositivo mobile. I dispositivi mobili hanno funzionalità limitate in termini di hardware e potrebbero anche avere una connessione Internet più lenta. Una notevole risposta del server può richiedere molto tempo per essere elaborata sul dispositivo stesso.
- The website will break if the API goes down
Bene, questo è un problema del sito Web, non dell'API. Il sito web deve essere sviluppato con cautela nel caso in cui l'API non sia disponibile. Questo potrebbe essere uno scenario reale, come se l'API venisse aggiornata e ridistribuita, il sito subirebbe un downtime e non funzionasse. Indipendentemente dal fatto che dipenda interamente dall'API o meno, devi fornire i mezzi per gestire con grazia gli errori: mostrare una pagina di errore adeguata o limitare la funzionalità di conseguenza.
- The website rendering time will be slower (will use ajax)
Non sono d'accordo. AJAX fa in realtà caricare il sito più velocemente. Ogni richiesta AJAX, se resa asincrona, renderebbe una parte separata del sito. Se si dovessero attendere tutte le porzioni da caricare contemporaneamente, il tempo di caricamento cumulativo difficilmente differirebbe. Inoltre, quasi tutti oggi usano AJAX, e questo ha dimostrato di non essere un problema, se fatto correttamente. Inoltre, AJAX è ampiamente utilizzato per apportare alcune elaborazioni al client, non al server, solitamente utilizzato come tecnica per ridurre il carico del server.
Utilizzo dell'API quando necessario: Svantaggi
- I'll have to manage user authentication, permissions and relations to his objects in the API
Se ti interessa, voglio dire se devi fare l'autenticazione e la sicurezza dell'utente da solo, quindi non dovresti fare affidamento sull'API completamente. Spesso accade che le persone sviluppino il proprio sistema e mantengano contemporaneamente sia gli account locali che quelli remoti (le API) - il concetto di account collegati. È un approccio popolare per il sistema con utenti già esistenti per fornire mezzi per collegare l'account utente, ad esempio, con l'account Facebook dell'utente.
Se desideri avere le tue informazioni sull'account utente, ma sei riluttante a gestire autonomamente l'autenticazione e l'autorizzazione, considera l'utilizzo di OpenID se l'API lo supporta, oppure considera l'implementazione di uno, se stai sviluppando anche l'API.
- Duplicate user data in my database and the API (I'll have a copy of the user objects)
Come per il punto precedente, è inevitabile che alcuni dati vengano ripetuti. Se l'utente oggetto del tuo progetto indica qualcosa di diverso dall'utente rispetto all'API, devi gestirlo da solo.
- Worried about the data sync (I'll update the database only on create/update/delete requests to the API)
Mantenere due sistemi distinti in sincronia è sempre stato uno sforzo di sviluppo serio. Se puoi evitarlo e affidarti interamente all'API, probabilmente preferiresti l'approccio API. Se l'API non ti fornisce tutte le funzionalità per il tuo progetto, allora potresti ancora dover affrontare questa attività di manutenzione.
Oltre alle tue preoccupazioni, devi prenderne in considerazione alcune aggiuntive:
- L'API garantisce la compatibilità a ritroso se introduce modifiche?
- L'API è documentata abbastanza bene da permetterti di coprire interamente gli aspetti del tuo progetto?
- Come si introducono correzioni / miglioramenti all'API? Esistono serie differenze tra il mantenimento e il miglioramento di progetti / API OpenSource e di quelli commerciali. Inoltre, qualsiasi progetto ha di solito una propria politica su quando è appropriato applicare alcune correzioni e modifiche (la maggior parte dei progetti open source lo farà più velocemente di un prodotto commerciale, che non è abbastanza veloce per te ) . Questo è qualcosa da considerare se si rileva un problema con l'API che infrange il codice. Se questo non è stato risolto dal team dell'API, lo faresti da solo per risolvere il problema.
A volte è accettabile non utilizzare direttamente l'API esterna, ma creare un'API di avvolgimento che è quella che useresti direttamente per il tuo progetto. Quindi delegare la disponibilità dell'API e i problemi di compatibilità al proprio wrapper API. In questo modo, le modifiche non influiranno direttamente sul sito Web o su altre applicazioni che lo consumano. Avrai anche la libertà di esporre l'API esterna in un formato più adatto. Ad esempio, potresti esporre un singolo metodo che comporta più chiamate all'API esterna, in modo da ridurre il numero di richieste del sito Web.
Come linea di fondo, le preoccupazioni reali che potresti avere sono la duplicazione dei dati e la disponibilità del sito in caso di arresto anomalo dell'API o di modifiche incompatibili. Deciderei in base allo sforzo di sviluppo stimato con entrambi gli approcci e alla probabilità di problemi con tale approccio.