API come nucleo per un sito Web e un'app mobile

Question

Ho diverse domande su un'idea di architettura completa. Spero che qualcuno con una grande esperienza possa aiutarmi perché sono praticamente bloccato in tutte le possibilità.

Sto pianificando di riscrivere un sito Web della comunità. Il nostro cliente desidera utilizzare app mobili native in futuro. Quindi dovrò tenerne conto. Per questo motivo ho deciso di creare un'architettura API REST al 100% basata sul framework PHP Kohana. Ho scelto Kohana perché questo rende scalabile l'API interna su un altro server molto facilmente senza molti sforzi extra. (Kohana minaccia le richieste di url interne non come HTTP, quindi non c'è molto sovraccarico all'inizio e può scalare su HTTP con alcune piccole modifiche al codice).

Inizialmente l'API sarà privata, ma in seguito potremmo renderla pubblica per consentire a più servizi di connetterci facilmente.

De struttura di base resto è come segue:

1. /gatti
2. /gatti/1
3. /gatti/1/custom

'custom' potrebbe essere 'bambino' per esempio.

stesso vale per:

1. /annunci
2. /offerte
3. /utenti
4. /banner
5. ecc ..

Si tratta di entità perfette per l'API perché l'app mobile utilizzerà sicuramente tutte queste funzionalità.

Quindi possiamo concludere che il nucleo del sito web è REST. Quindi in pratica voglio rendere il sito Web un client dell'API proprio come l'app nativa in futuro. In questo modo la manutenzione sembra molto più semplice.

Ciò che mi preoccupa è il fatto che c'è molto più di questo (gestione dei file caricati, fatturazione, fatture automatiche per la fatturazione, e-mail per gli annunci e così via). Il caricamento dei file deve passare attraverso il sito Web all'API. È questa pratica comune? Se non lo faccio, il sito web farebbe la logica di caricamento, il che rende il sito non più client e l'app stessa. Pertanto, l'app mobile non può nemmeno essere caricata e sia l'API che il sito Web devono conoscere la cartella di caricamento (logica duplicata).

ho pensato di creare le seguenti moduli:

1. comunità-api
2. comunità sito

Api sembra essere il nucleo allora. Ma ... che dire di cronjobs ecc? In realtà, non dovrebbero far parte del sito Web, in quanto si tratta solo di un "cliente". Sento che dovrebbero interagire direttamente con il modello o l'API.Quindi, in pratica l'API diventa più simile a un gateway per il core e pensiero che ho bisogno di questo:

1. comunità-core
   • modelle
   • Cronjobs
   • Auto indirizzi (parte di cronjobs)
     • Fatture, ecc
2. comunità-api
   • Interagisci con i modelli a nucleo attraverso HTTP
3. comunità sito
   • Sito
   • Admin

Il nucleo cronjob s sono un'eccezione alla struttura REST. Sono gli unici in grado di modificare i dati senza passare attraverso l'api. Almeno questa è stata la mia idea perché appartengono al nucleo e l'API è in cima al nucleo.

Ma dal design sembra sbagliato. La manipolazione dovrebbe solo passare attraverso l'API!

Alternativa:

1. comunità-core
   • modelle
2. comunità-api
   • Interagisci con i modelli a nucleo attraverso HTTP
3. comunità di business
   • cronjobs
   • Auto invii (parte di cronjobs)
     • fatture ecc
4. comunità sito
   • Sito
   • Admin

Questo aspetto migliore di progettazione per me. Mindmap illustration http://mauserrifle.nl/mindmap.jpg

Domande principali

1)

caso cronjobs manipolare tramite l'API o nucleo modelli?

2)

mia fattura cronjob ha bisogno di un modello più o meno lo stile del sito principale, naturalmente. Ma se il mio cronjob fa parte del business o core, non avrà conoscenza del mio sito principale. Cosa ha senso risolvere questo?

3)

Mio sito verrà utilizzato baffi come un motore di template. (sia php che javascript possono analizzare questi modelli). Ho pensato di utilizzare l'API direttamente per le chiamate Ajax ma poi ho realizzato:

Il sito ottiene i dati da API, formatta i timestamp alle date (Y-m-d) per il modello e quindi esegue il rendering. Se permetto a javascript di chiamare direttamente l'API, anche javascript deve avere una logica (formattazione). Questo è un codice duplicato! Sembra che l'unica soluzione sia chiamare il sito Web per ajax (che chiama l'API e i formati) e restituire il json formattato. Ho ragione?

Ma .... chiamate semplici come l'eliminazione di un annuncio può passare attraverso l'API direttamente (ad esempio DELETE:/ads/1

ho un mix di chiamate ....

Qualsiasi soluzione migliore per questo

4)

Globale:? la mia architettura troppo complesso? Qualche alternativa dovrei prendere in considerazione?

Mi piacerebbe sentire il vostro feedback!

Answer 1

Una volta che ho sentito che un buon modo per sviluppare un'applicazione web è sviluppare uno API-Centric Web Application. Il fatto è che, se accoppi il servizio principale all'API pubblica, creando un'applicazione API-Centric, perdi l'intero punto di sviluppo di un'API pubblica.

Answer 2

Questo non mi sembra logico.

Sì, l'API e il sito Web e ciò che potrà mai succedere dopo sono cose separate e il sito Web dovrebbe essere un client per l'API stessa ma poiché semplificherebbe le cose, credo che dovresti RE-USE le classi di dominio per costruire e basare la logica del tuo sito web. In questo modo puoi utilizzare lo stesso codice base e gestire tutti i tuoi problemi, inclusi annunci, fatturazione e, naturalmente, upload di file con facilità.

Per l'API pubblica, se possibile riutilizzare le stesse classi di dominio con diversi metodi di autenticazione, in modo che qualsiasi problema si verifichi, non influirà sul servizio principale.

vostri cron-job deve essere utilizzato solo per sparare la chiamata tramite l'API stesso e quelle chiamate devono essere effettuate sul l'applicazione principale (sito web tramite l'API)

Se si crea il tuo sito web senza ripetere da-te, come in, usando lo stesso codice della base e avvolgendo l'app web attorno ad esso, non si avrà il problema di sollevare in q # 2.

La stessa cosa si applica alla domanda numero 3. Se si avvolge il sito Web attorno all'API, il sito Web può utilizzare l'API stessa senza essere un'entità separata.

La tua architettura sembra complessa ma se fai queste cose, sarà semplice.;-)

Buona fortuna!

Answer 3

REST è solo un modo per avviare una richiesta. Il codice principale che elabora la richiesta non deve essere strettamente accoppiato all'interfaccia REST o HTTP per quella materia. Ti consiglierei di progettare la tua API REST come un semplice mapper per un file di inclusione o qualcosa di simile. Il cron potrebbe quindi bypassare l'intera API REST e includere direttamente il file. Separare l'interfaccia di richiesta dal codice che esegue l'elaborazione effettiva.