Devo utilizzare la mia API pubblica per la mia interfaccia web?

Naviga le tue risposte
4

Sto progettando un'API con django e il suo resto framework (e non sono sicuro che valga la pena di passare alla versione o meno).

So perfettamente che le app iOS e Android chiameranno l'API, riceveranno un token (forse con scadenza ho bisogno di leggerne un po 'di più) e poi userò questo token all'interno di ogni chiamata successiva per poter autenticare.

Ma la mia domanda principale è: la mia interfaccia web dovrebbe utilizzare l'API?

Dato che non sembra molto pratico, preferisco vedere me stesso usare sessioni e cookie e fare in modo che i modelli di back-end facciano passare i dati attraverso di essa piuttosto che ottenere un token e fare chiamate AJAX per tutto.

    
posta soueuls 07.11.2015 - 22:03
fonte

2 risposte

2

Questi sono argomenti per la creazione di SPA che mi convincono:

  1. Vuoi che l'applicazione sia utilizzabile offline? dai un'occhiata a come si comporta Gmail in assenza di connessione. La funzionalità è molto limitata, ma è ancora utilizzabile. Le cose possono essere fatte un passo avanti poiché HTML5 offre molte opzioni per l'archiviazione lato client. La memoria lato server può essere considerata solo come componente di backup e sincronizzazione. Rende il client fault-tolarant .
  2. Quanto velocemente vuoi che la tua applicazione risponda dopo ogni clic? Secondo le ricerche fatte su Google, gli utenti ritengono l'applicazione altrettanto veloce e responsive se c'è un feedback dopo meno di 200ms. Se qualcosa può durare più a lungo, dovrebbe apparire un'indicazione di funzionamento a lunga durata (spinner o barra di avanzamento). Queste cose sono fattibili solo in SPA.
  3. Perché vuoi trattare un tipo di client in modo speciale? L'implementazione del codice lato server solo per un tipo di client probabilmente produrrà più codice scritto. Un problema di semplicità dell'architettura del sistema e probabilmente anche SECCO .
  4. L'API è un confine ben definito che rallenta l'entropia del software . Unico fatto che esiste un'API da progettare costringe a una buona pratica di progettazione del software. La mancanza di limiti ben definiti può (in tempo) ridurre manutenibilità di un sistema, a causa di interdipendenze accidentali aggiunte. Questo diventa significativo in basi di codice più grandi.
  5. Lo spostamento della logica di presentazione al client riduce le risorse necessarie sul server . Potrebbe ridurre significativamente i costi del progetto, in base alla tecnologia utilizzata, alle dimensioni del progetto e a quanto il progetto riguarda la presentazione. Ho visto un progetto in cui metà delle risorse lato server sono state utilizzate dalla logica di presentazione e dall'archiviazione di sessione (ha utilizzato ampiamente JSF).

Quindi, se nessuna delle questioni di cui sopra nel progetto e la conoscenza di JavaScript sono limitate nel team, potrebbe essere una buona idea attenersi al rendering del template lato server vecchia scuola.

La tua domanda mi ha motivato a scrivere un blogpost sulla SPA .

    
risposta data 08.11.2015 - 08:31
fonte
0

È un approccio valido per utilizzare un'API direttamente dal client web.

Questa API deve supportare un modo per creare una sessione utente e restituire un token che il client trasmetterà ad ogni chiamata.

Riesco a vedere i seguenti vantaggi per questa soluzione

  • Tutti i tuoi clienti (mobili, web, esterni) utilizzano la stessa API, che può semplificare la manutenzione e il ridimensionamento
  • Mantenere la responsabilità del rendering HTML interamente sul client lato, che è ben supportato dagli attuali framework javascript.

Un approccio alternativo è creare un livello sulla tua API web, ovvero rendering, gestione delle sessioni. Non l'ho fatto perché sembrava molto più complicato del necessario.

    
risposta data 08.11.2015 - 04:25
fonte

Leggi altre domande sui tag

Node.js callbacks e questo - come dovrebbe essere risolto? Domanda di progettazione DDD