Sito web completamente basato su API - è una buona idea?

2

A volte ho sentito che rendere il sito web completamente basato su API, nel senso che anche nel browser la pagina è costruita sulla base dell'endpoint API e praticamente nient'altro.

Uno dei vantaggi che vedo in questo è che quando crei un'applicazione per smartphone hai già API che funzionano e sono testate. E nel caso tu abbia bisogno di cambiare qualcosa, puoi cambiare praticamente l'app per desktop e per dispositivi mobili nello stesso momento (con alcune modifiche forse).

Forse ho in qualche modo frainteso l'idea, ma ho alcune domande su tutta la sua fattibilità. Sfortunatamente non sono riuscito a trovare nessun buon articolo su questo argomento (il che è strano, forse è perché questo non è ciò che le persone fanno e ho appena frainteso completamente).

Per esempio, per essere chiari sull'ambito di applicazione, diciamo che stiamo costruendo un sito di social-network.

  1. Per le API di sviluppo mobile è il modo predefinito, ma per il desktop sembra essere eccessivo per me. Sono abituato al framework Django e si può fare abbastanza facilmente il rendering delle pagine - il browser invia la richiesta GET o POST con i parametri e si rende una pagina di risposta, non può essere più semplice. Ma se decido di utilizzare l'API sul browser desktop, invece di una semplice richiesta, ho bisogno di costruire JSON, inviarlo all'endpoint API, deserializzare e quindi eseguire il rendering di una risposta. E a differenza del solito modo, in cui posso generare una risposta molto complessa in un solo passaggio - con gli endpoint dell'API potrebbe essere necessario utilizzare diversi endpoint per generare pagine Web desktop con molti contenuti, ovvero finisco per inviare più richieste API. Quindi, utilizzando l'API per tutto ciò che riguarda la versione desktop del sito, aumento il numero di richieste al server e anche la quantità di codice necessaria. Sì, risparmierò tempo a sviluppare l'app per dispositivi mobili, ma a costo di una maggiore larghezza di banda e di una minore robustezza, il che non va bene secondo me. Forse non capisco qualcosa, sarebbe bello se qualcuno potesse spiegarlo.
  2. Ha davvero senso fare la versione desktop basandosi sugli endpoint API ovunque? Ho visto persone che ne parlano a volte, ma non ho mai visto esempi o grandi articoli a riguardo, il che mi suggerisce che forse questa è davvero un'idea stupida e sto sprecando il mio tempo anche a pensarci. Qualcuno realmente fa un grande sito web desktop dove ogni piccola cosa è legata agli endpoint API? Potrei non avere molta esperienza, ma per quanto ne so sono solitamente chiamate API piccole quando sono utili, ma non tutta la struttura si basa sull'API (a differenza delle app mobili). Quindi dovrei attenermi al solito sviluppo e lasciare l'API quasi esclusivamente alle app mobili?
posta ScienceSamovar 05.10.2016 - 12:40
fonte

2 risposte

3

Sembra che tu stia parlando di una "app a singola pagina"

Questo termine viene utilizzato per fare riferimento a siti Web in cui tutte le o più azioni intraprese vengono eseguite tramite chiamate javascript AJAX lato client, che recuperano json, convertono tale json in html e aggiornano la pagina

anziché:

Avendo il browser richiesto una nuova pagina html che viene restituita e mostrata dal browser, scartando la vecchia pagina.

Anche se sono d'accordo sul fatto che ci siano degli aspetti negativi di questo approccio, ora è l'architettura standard di fatto per la progettazione di siti web. Il semplice motivo è che AJAX offre un'esperienza utente nettamente migliore rispetto ai carichi di pagina.

Sono disponibili diversi framework javascript come react e angular per rendere questo approccio facile da implementare.

Quindi, la maggior parte delle "app a singola pagina" sono NOT tutte eseguite su una singola pagina. Le pagine di amministrazione, le impostazioni ecc. Nella mia esperienza sono solitamente suddivise, in quella che effettivamente è una singola "app a pagina singola". es. hai un Admin.html che usa anche l'angolare o qualsiasi altra cosa e ha un set di apis per fare la sua funzionalità nella pagina.

In questo modo è più semplice separare le preoccupazioni e affrontare alcuni problemi che le app a singola pagina tendono ad avere con l'autenticazione.

L'esperienza utente non è molto influenzata, perché il passaggio tra queste sezioni del sito non è qualcosa che fanno spesso e viene visto come un "grande passo" con l'intera pagina che cambia.

Tuttavia, dovresti considerare attentamente dove questo approccio sia ragionevole. avere alcuni moduli di invio tramite standard http e alcuni tramite il framework js mi sembra di non aggiungere alcun vantaggio. Se si utilizza un framework, attenersi ad esso e utilizzarlo per tutto. Se stai facendo il vecchio skool html, atteniti a quello. la combinazione di entrambi gli approcci significherà semplicemente che ottieni i lati negativi di entrambi.

    
risposta data 05.10.2016 - 13:10
fonte
2

Ha senso avere un'API condivisa dietro ogni modo di accedere al tuo sistema. Dietro questa API puoi gestire preoccupazioni ripetute, come le entità che hai e come vengono caricate dal database, o come gestire l'autenticazione e l'autorizzazione dell'utente. Dovresti mirare alla differenza tra due client diversi, come il cellulare e il desktop, per essere limitato alle loro differenze effettive, senza duplicare il codice.

Tuttavia, ciò non significa che è necessario riutilizzare i servizi Web per tutti i front-end. Qui ci sono diverse opzioni:

  • Un'API condivisa, un insieme di classi, che viene inserito una volta nei servizi Web e una volta nelle pagine Web (sul lato server)
  • Utilizza i servizi Web come API, ma chiamali dall'interno del server per eseguire il rendering delle pagine web lato server
  • Utilizza i servizi web come API e chiamali dal client.

Ritornando alla tua domanda:

Does it really make sense to do desktop version relying on API endpoints everywhere?

Sì, è logico che la versione desktop si basi sulla stessa API della versione mobile. No, non deve essere sotto forma di endpoint del servizio Web.

Esaminando queste scelte, potresti essere interessato al pattern backends-for-front-end .

    
risposta data 05.10.2016 - 14:37
fonte

Leggi altre domande sui tag