È una cattiva scelta consumare anche l'API REST dal back-end?

Disaccoppiare i componenti dal database / allontanarsi dalle connessioni dirette del database è uno schema comune. Spostare l'accesso al middleware / un componente che front-end il database può contribuire a migliorare la sicurezza e la modularità e fornire un luogo per implementare la convalida e l'interpretazione dei dati che altrimenti "ricadono" in SQL, stored procedure e codice di database sul lato client. A fronte di ciò, è necessario valutare lo sviluppo, il tempo di esecuzione e, eventualmente, il costo economico del front-end del middleware / gestione dei dati. Ma in molti punti di scala del progetto, i front-end dei dati sono spesso considerati una buona scelta.

Se controlli il design e i componenti del backend, utilizzando un'API RESTful, specialmente nel suo formato comune, ad es. servito da HTTP e codificato con JSON - è notevolmente inefficiente rispetto ad altre alternative (es. link diretto alla libreria, Protocol Buffers , < a href="http://en.wikipedia.org/wiki/Protocol_Buffers"> Risparmio , vari tipi di ESB , altri meccanismi RPC, ...) che non passano attraverso un ciclo serialize-to-text, serve, deserialize-from-text per ogni chiamata API. REST è anche semanticamente migliore di un meccanismo di interazione a lunghezza di braccio, dato che alcuni costrutti (per esempio transazioni multi-step, streaming, oggetti binari di grandi dimensioni, eccezioni, consegna garantita, ...) sono più semplicemente, puliti o gestiti direttamente con altre forme di interazione.

Alcuni motivi per cui potresti ancora voler utilizzare un backend RESTful: semplicità, coerenza (ogni client, locale o remoto, passa attraverso una sola API) e time-to-market (es. non aver bisogno di imparare un'altra API / stile di interazione ). Questi presuppongono che stai esponendo il tuo database, relativamente direttamente, attraverso l'API RESTful. Se è strettamente per l'uso di componenti sotto il tuo controllo, REST non è probabilmente la scelta migliore (per ricchezza semantica o efficienza).

Penso che la giustificazione generale di rendere i dati accessibili a un'API RESTful sarebbe la relazione che l'accesso ai dati avrebbe sul resto dell'ambiente.

Pensaci, la potenza dell'API è in genere la grande quantità e varietà di implementatori "client" che possono consumarlo. Questo non dovrebbe essere diverso nel tuo caso.

In altre parole, se dovessi avere più utenti e diversi invocati di questo stesso accesso ai dati e / o cercare di ridimensionarlo, allora penso che avrebbe senso.

Ma al contrario, se si ha un singolo consumatore e questo accesso ai dati e la logica sono adattati in modo molto specifico per non ridimensionare, non so cosa si otterrebbe dal fare il trasferimento di bit attraverso un'API RESTful.

Non necessariamente. Il middleware non può gestire tutto. Ci sono tre esempi che mostro sempre per mostrare questo: batching, forward e api concatenare. Questi trarranno tutti vantaggio dal rimanere entro i limiti della richiesta originale, ma nelle applicazioni, spesso devono uscire e rientrare tramite il gate proxy / api.

Estraendo l'I / O dall'api e spostandolo su un intercettore, puoi usare un prehandler / posthandler per distribuire le comunicazioni e utilizzare un thread per gestire il ciclo.

Il flusso I / O da gate api all'istanza dell'applicazione a tool di risposta è un flusso costante e non è interrotto.

Vedi api astrazione e api concatenamento per maggiori informazioni ( link )

L'utilizzo dell'API REST dal back-end presenta due vantaggi: non è necessario sviluppare e documentare un'altra API e si dispone solo di un set di bug, non di due.

Ci sono due possibili obiezioni: potrebbe essere che il tuo backend faccia cose che non si adattano all'API esistente (perché potrebbe guardare i dati dalla direzione opposta come fa l'API frontend). E potrebbero esserci problemi di prestazioni: se il back-end utilizza il database dieci volte di più del front-end, e questo è critico dal punto di vista delle prestazioni, allora non vuoi l'API più semplice, ma il più veloce.

Quindi controlla come il tuo back-end userà il database e deciderà da lì. Se il tuo back-end è soddisfatto della funzionalità dell'API REST e non ci sono problemi di prestazioni, utilizza l'API REST.

Un sacco di buone risposte e commenti. Per me, sembra orientato al microservizio. La sfida è che c'è un leggero sovraccarico che inserisce un livello tra l'accesso ai dati e il codice backend che agita su quei dati. Overhead in termini di tempo di sviluppo e amp; cicli e sovraccarico in termini di prestazioni del codice. Ma i lati positivi sono che i componenti dell'applicazione sono più liberamente accoppiati in modo da poter estendere / modificare il codice con meno complessità. Se tutto ciò che accede ai dati avviene tramite l'API, allora qualsiasi modifica che devi apportare al modello di dati sottostante se rendi l'API perfettamente gestibile, allora hai finito.

Al contrario, se diverse parti del tuo codice stanno accedendo ai dati in più punti, hai più da considerare, da fare e da testare. Inoltre, quando ci sono più posti in cui il codice backend accede ai dati, tende ad essere incoerenza.