L'API REST può essere utilizzata come livello aziendale?

Il problema che vedo con il tuo approccio è che stai costruendo un'API REST per un solo consumatore, i tuoi controller, e questo è eccessivo. Non aggiungere semplicemente un livello solo per passare i dati da un livello a un altro, non c'è motivo, creerai lavoro per te senza ulteriori vantaggi.

Un modo (rapido) per rendere la tua API utile sarebbe se fosse l'unico endpoint che i tuoi controllori (ad esempio la tua applicazione) abbiano mai bisogno. Considera questo:

All'improvviso l'API REST ha uno scopo, ovvero fornire un'interfaccia unificata ai vari fornitori di dati. Non è necessario che la tua applicazione sia a conoscenza dell'API di Google o di Trello o di qualsiasi altro fornitore di dati che potresti utilizzare in futuro, ma solo della tua API REST.

Questo disegno, anche se leggermente più utile, è ancora eccessivo se la tua applicazione è l'unico consumatore. L'obiettivo principale della creazione di un'API REST consiste nell'esporre un'interfaccia pubblicamente disponibile per la condivisione delle applicazioni. E la chiave qui è l'esposizione, la tua API REST sarà disponibile per il mondo e quindi deve essere sicuro. L'autenticazione e l'autorizzazione dell'API non sono semplici attività, se solo un'applicazione utilizza la tua API, perché affrontare tutti i problemi? A meno che non si voglia sperimentare e imparare. Se questo è il caso, con tutti i mezzi per farlo.

In ogni caso, le prestazioni non dovrebbero essere un problema. Dovresti aggiungere un ulteriore livello, quindi ovviamente ci sarà un sovraccarico, ma se il sovraccarico sarà significativo o meno dipende interamente dalla tua implementazione. Se la tua API REST è il singolo endpoint, allora sarà probabilmente una buona idea anche quella dove si verifica la memorizzazione nella cache. E non solo il caching lato server, l'API REST rende il caching del browser un po 'più facile da sfruttare e, se hai ragione, le prestazioni generali della tua applicazione potrebbero aumentare, confrontandole con un approccio non REST.

tl; dr: non costruire cose che non hanno uno scopo reale (a meno che tu non stia imparando).

In base al tuo disegno, sembra che ci debba essere un modello chiamato dal tuo controller che si occupa di parlare con Google, ottenere i risultati, formattarlo per la tua app, e quindi che viene inviato al controller pronto per l'uso. In altre parole tutti i dettagli specifici di google sarebbero in quel modello. lo stesso per trello. in questo modo se hai bisogno di aggiungere più API da consumare, hai mantenuto tutto bello e separato.

questo è un piccolo dettaglio - ma ricorda nella progettazione generale dell'app - devi tenere conto di possibili ritardi nell'invio / recupero delle informazioni dal server API al tuo server. in altre parole, assicurati che la tua app non si blocchi completamente se il server trello è lento o inattivo.

Gli Apis devono preoccuparsi della sicurezza, ma non devono necessariamente essere "pubblici". molte API sono business to business con niente di pubblico.

Ho letto la maggior parte di questo libro - la sua versione breve, ancora in anticipo, e non abbastanza esempi - ma è molto attuale, è tutto php, e l'autore sta attivamente creando e insegnando su apis. link

l'autore ha post relativi a php rest api sul suo blog. link

e sii sicuro e leggi i commenti per i post delle API! seriamente ti darà una prospettiva molto preziosa.

Suggerisci google "hypermedia" e api. potresti non volerlo usare, ma ti mostrerà altre tecniche per la creazione di API.

Ho appena aderito ai programmatori - avrei alzato questa domanda se potessi! la maggior parte delle aziende non sarà in grado di creare applicazioni completamente nuove per il consumo o la pubblicazione di apis. in modo che vengano in mente le migliori pratiche per l'integrazione di apis in framework mvc esistenti - questo è davvero importante.