Distinzione tra API e frontend-backend

Sto cercando di scrivere un sito web aziendale "standard". Per "standard", intendo questo sito esegue i soliti HTML5, CSS e Javascript per il front-end, un back-end (per elaborare roba) e esegue MySQL per il database. È un sito CRUD di base: il front-end rende praticamente tutto ciò che il database ha in serbo; il back-end scrive nel database qualunque sia l'utente acceda e fa un po 'di elaborazione. Proprio come la maggior parte dei siti là fuori.

Nel creare i miei repository Github per iniziare la codifica, mi sono reso conto di non capire la distinzione tra back-end front-end e API . Un altro modo di formulare la mia domanda è: da dove viene l'API in questo quadro?

Elencherò alcuni ulteriori dettagli e poi le domande che ho - spero che questo vi dia un'idea migliore di quale sia la mia vera domanda, perché sono così confuso che non conosco la domanda specifica da porre.

Alcuni dettagli in più:

• Vorrei provare il modello Model-View-Controller. Non so se questo cambia la domanda / risposta.
• L'API sarà RESTful
• Vorrei che il mio back-end usasse la mia API invece di consentire al back-end di imbrogliare e chiamare query speciali. Penso che questo stile sia più coerente.

Le mie domande:

• Il front-end chiama il back-end che chiama l'API? Oppure il front-end chiama semplicemente l'API anziché chiamare il back-end?
• Il back-end esegue semplicemente un'API e l'API restituisce il controllo al back-end (in cui il back-end funge da controller finale, delegando le attività)?

Sono incoraggiate risposte lunghe e dettagliate che spiegano il ruolo dell'API accanto al back-end front-end. Se la risposta dipende dal modello di programmazione (modelli diversi dal modello Model-View-Controller), descrivere questi altri modi di pensare all'API. Grazie. Sono molto confuso.

Penso che tu sia confuso dal modo in cui il termine API viene abusato e abusato da molti sviluppatori web.

• API significa Application Programming Interface, ovvero qualsiasi interfaccia ufficialmente specificata tra sistemi diversi (o parti dello stesso sistema).
• Qualche tempo fa, è diventato molto importante per l'avvio Web offrire l'accesso pubblico ad alcuni dei loro dati interni tramite un'API del servizio Web, in genere utilizzando REST e JSON, consentendo così agli sviluppatori di terze parti di integrarsi con i loro sistemi. Gli sviluppatori Web hanno iniziato a utilizzare il termine "API" per indicare in modo specifico (e solo) "servizio Web accessibile pubblicamente" e ad abusarne per includerne l'implementazione.
• In termini di frontend e backend, questa API del servizio Web (e la sua implementazione) è il backend . Alcune parti possono essere accessibili pubblicamente e altre solo al tuo frontend.
• Un nome diverso per questo è "livello di servizio", cioè codice che
  • rappresenta i servizi che il frontend chiama
  • non contiene alcuna logica di visualizzazione (dopo tutto è il lavoro del frontend)
  • è più astratto e a grana grossa rispetto alle semplici azioni CRUD (una chiamata di servizio comporta spesso più azioni CRUD e deve essere eseguita all'interno di una transazione di database).
  • contiene la logica aziendale dell'applicazione

Delineamo un'architettura "tipica" di un sito Web, con un "front-end" e un "back-end". E dal momento che è un sito Web, avremo anche esplicitamente un "client". (Dato che in un browser JavaScript non ha modo di chiamare direttamente MySQL su un server.)

Per chiarezza, i termini che stiamo usando sono:

• Client : il browser conforme a HTML5, esp. il DOM e il JavaScript lì caricati per manipolarlo.
• Front-End : il server PHP a cui punta il DOM, contenente sia la singola pagina richiesta sia alcuni punti di accesso XML o JSON in stile AJAX.
• Back-end : un server di database in cui è in esecuzione MySQL.

Per un programma correttamente progettato, ciascuno di questi componenti ha un'API privata per comunicare con gli altri. Il codice PHP "front-end" non emette SELECTdirettamente istruzioni SQL arbitrarie , ma piuttosto chiama stored procedure, SQL pre-autorizzato o persino chiamate PHP distinte a un'istanza completamente diversa di PHP che viene eseguita sul server back-end . Queste stored procedure o chiamate HTTP distinte sono esse stesse un'API.

La definizione non cambia anche se permettiamo una certa impurità del nostro design. Se il tuo PHPfile scrive e invia una stringa SQL direttamente a MySQL, È ANCORA UN'API , anche se molto insolita che difficilmente potresti ripetere.

Nota che è del tutto possibile che il tuo php front-end sia rigorosamente sincrono, senza alcun voodoo AJAX. Se chiamate le stesse funzioni PHP esterne in detto file sincrono, potreste considerarle come usare la stessa API della versione lato client, sebbene l'uso del termine "API" qui non possa dare alcuna reale chiarezza.

Un'API come interfaccia di programmazione dell'applicazione , dopo tutto, e si riferisce davvero a qualsiasi momento in cui un programma chiama al di fuori del proprio processo. Se stai scrivendo un progetto che ha sia un front-end che un back-end, siano quelli AJAX / PHP / MySQL come sopra o MS Access / SQL Server, vale la pena specificare esplicitamente come ti chiamerai l'un l'altro, se non altro per rendere più facile sapere dove cercare quando qualcosa si rompe.

(E l'argomento dell'API pubblica è qualcosa di completamente diverso. Nel nostro esempio sopra, solo l'URL visualizzato nel client è una "API pubblica". Tutto il resto è, in sostanza, "privato". Come in, non ti aspetti qualsiasi codice al di fuori del tuo controllo per chiamare l'API interna e negherai direttamente tali risultati o ti riserverai il diritto di farlo in futuro.

un'API gestisce le richieste http come GET, POST, FETCH, DELETE ... che possono essere utilizzate a seconda dell'accesso token per recuperare i dati in un formato specifico come json, xml, ecc.

Questi "dati" possono essere utilizzati nella propria applicazione per ottenere API (Application Programming Interface) che è un servizio Web accessibile al pubblico per raccogliere dati che potrebbero essere interessanti per alcuni utenti.

Questi dati potrebbero restituire un set di dati che lo rappresentano non riuscito o recuperare i dati dal suo server API

L'API è pensata per essere back-end, quindi può essere utilizzata in qualsiasi ambiente front-end. Ciò significa che può essere utilizzato in un'applicazione web, android, ios ... in grado di gestire richieste https