Il miglior metodo di comunicazione tra la tua app e il tuo sito web? PHP, servizio Web, ecc

Raccomando di creare un'API REST per la tua applicazione e il tuo sito web.

Costruire un servizio Web è più lavoro, ma penso che sia molto più pulito. Se lo fai in questo modo, né il tuo sito web né la tua applicazione devono preoccuparsi di come connettersi e interrogare il database poiché tutti questi dettagli saranno astratti dall'API. Inoltre, un altro vantaggio è la sicurezza: se il tuo sito web viene mai violato, non avrà necessariamente accesso al tuo database poiché il sito sta facendo solo chiamate API (e non chiamate database). Naturalmente ci sono molte cose da considerare con sicurezza, ma questa è una cosa in meno di cui ti devi preoccupare.

Ecco una fantastica guida introduttiva su come creare un'API REST in PHP:

link

A seconda della complessità dei tuoi requisiti, servizi web REST / JSON o SOAP.

Per semplici requisiti REST è più semplice da capire e implementare, specialmente se si preferisce JSON su XML.

Tuttavia, se i tuoi requisiti includono l'autenticazione, la verifica dei messaggi, l'individuazione, la non ripudiabilità o lo schema di messaggi complessi, potresti essere meglio immergerti nelle complessità di SOAP dato che quasi tutti i problemi sono trattati. Sebbene SOAP sia più complesso e più difficile da capire, si occupa di quasi tutte le permutazioni architettoniche e le variazioni possibili in un sistema di messaggistica, in più ha un set di strumenti molto maturo e completo per aiutarti nel labirinto delle API. Ma se non hai bisogno di questo livello di sofisticazione, rimani con REST.

Il più grande svantaggio di un'API è che ti stai assumendo la responsabilità di fare richieste JSON, convertire le risposte e mostrarle sulla pagina come responsabilità del browser. Non tutti i browser possono essere all'altezza, intrinsecamente o perché gli utenti hanno disattivato java-script.

Queste preoccupazioni sono diminuite nel tempo, tuttavia, e ora interessano relativamente pochi clienti. Tuttavia, potrebbe valere la pena di lavorare in più per supportare tutti i client.

I vantaggi di un'API sono che è molto più semplice separare la logica dell'API dai dettagli del display ed è più facile accedere direttamente all'API con mezzi diversi da un browser (ad esempio da un'altra applicazione). Questo rende automaticamente il test dell'API separato dal test del client, che è buono.

È anche un po 'più sicuro contro gli attacchi di page injection (come gli attacchi cross-site scripting) perché è più semplice analizzare ed uscire correttamente da JSON che non per un documento HTML (che potrebbe includere tag di script contenenti java-script). Ciò presuppone che sul client si analizzi JSON con un parser JSON e non si usi solo una forma di eval (), che non è affatto sicura.

Un altro possibile vantaggio è che è possibile eliminare il livello del "framework Web". Invece di ASP, JSP, Django, Zend, o qualsiasi altra cosa, hai davvero bisogno di un sottile strato per inoltrare JSON avanti e indietro dal tuo client al tuo server. Quindi, come minimo, potresti portare quel pezzo tra i quadri in un modo banalmente semplice, se lo volessi. Questo può eliminare una grande parte mobile dalla tua applicazione.

Penso che la crittografia e la validazione funzionino praticamente allo stesso modo in entrambi i casi. Penso che se hai un'API è più probabile che tu ricordi di non fidarti del client che se hai una pagina web, dato che è possibile dimenticare che gli aggressori non hanno bisogno di usare un browser come client ma possono inviarti delle intestazioni , parametri di ricerca e dati di post che vogliono. Questo è più di un problema psicologico che tecnico e potrebbe non essere adatto a te.