Architettura API interna ed esterna

L'azienda per cui lavoro mantiene un prodotto SaaS di successo che è cresciuto "organicamente" nel corso degli anni. Stiamo programmando di espandere la linea con una suite di nuovi prodotti che condivideranno i dati con il prodotto esistente. A supporto di ciò, stiamo cercando di consolidare la logica aziendale in un unico posto: un livello di servizio Web. Il layer WS verrà utilizzato da:

• Le applicazioni web
• Uno strumento per importare dati
• Uno strumento per l'integrazione con altri software client (non un'API in sé)

Vogliamo anche creare un'API che possa essere utilizzata dai nostri clienti in grado di utilizzarla per creare le proprie integrazioni. Stiamo lottando con la seguente domanda:

L'API interna (ovvero il livello WS) e l'API esterna devono essere una sola cosa, con le impostazioni di sicurezza e autorizzazione per controllare cosa può essere fatto da chi, o dovrebbero essere due applicazioni separate in cui l'API esterna chiama semplicemente l'API interna come qualsiasi altra applicazione? Finora nel nostro dibattito sembra che separarli potrebbe essere più sicuro, ma aggiungerà spese generali.

Cosa hanno fatto gli altri in una situazione simile?

È sempre bello mangiare il proprio cibo per cani. Un'API dovrebbe inoltre essere più semplice da gestire rispetto a due, anche se si tiene conto di alcune spese generali per l'autenticazione e l'autorizzazione.

Anche se sono d'accordo con Aneurysm9 a volte non vuoi esporre tutte le funzionalità del tuo sistema. In questo caso sarebbe preferibile avere due API ... MA se lo fai in questo modo ... assicurati che tutte le funzionalità comuni condividano la stessa API, IE che una sia una versione estesa dell'altra invece di due distinte set di codice.

In questo modo puoi usare il tuo per te stesso mentre hai un posto dove i lavori privati, sensibili e sperimentali possono progredire, pur consentendo di pubblicare e utilizzare le nuove cose senza modificare troppo l'API pubblica.

L'ho già visto (molte volte) e quello che ho preferito preferire è:

Elimina il BL dal sito Web. Trasforma il sito Web in un consumatore dell'API. Tratta il sito Web come un altro client della tua API. La tua API È il servizio.

Se ti ritrovi a pensare che hai bisogno di metodi API speciali solo per il sito Web, ripensaci! Se fa bene all'oca, fa bene al gander. Se davvero hai davvero bisogno di funzionalità speciali per il sito web, suggerirei che ciò che hai davvero trovato è una differenza nel "profilo utente" e quindi questa è una situazione in cui l'API dovrebbe ancora supportare le funzioni "speciali", ma poi tu controllarli tramite autorizzazione.

Non convinto?

Fai un ulteriore passo avanti nel paradigma ...

L'app del telefono è in esecuzione su una piattaforma in cui viene eseguito il bytecode, l'app vive nel telefono e consuma i servizi API tramite HTTP / JSON

Il sito Web è un'app in esecuzione su una piattaforma in cui viene eseguito HTML + Javascript, l'app vive nel browser e consuma i servizi API tramite HTTP / JSON

Lo stesso!

Estendilo a tablet, TV, altre piattaforme telefoniche, plugin, app di terze parti, mashup, ...

Molte esperienze utente diverse sono tutte collegate a un'API comune.

L'app è l'API. Il sito Web è solo un client (di molti)

Usa un'API

Se stai implementando l'API di servizio come livello REST, aggiungi semplicemente l'autenticazione alle route protette.

Probabilmente ti consigliamo di utilizzare un framework di sviluppo che non produca troppa 'magia'. Qualcosa in cui è possibile definire i percorsi direttamente senza molta ingegneria inversa.

Pensa a qualcosa come Node.js / Express, python / pylons, python / google engine app, ecc.

Di recente l'ho implementato su Google App Engine per un'API REST / Datastore e non penso che avrebbe potuto essere più semplice. I controller sono implementati come classi e le loro successive richieste HTTP (ovvero GET / POST / PUT / DELETE) sono implementate come metodi di tali classi. Sono riuscito a implementare basic-auth come decoratore. Ciò ha reso l'aggiunta di un requisito di autenticazione a una richiesta semplice come allegare il decoratore @basicAuth.

In questo modo, potrei rendere pubbliche le richieste GET in entrata per aggiungere un requisito di autenticazione alle richieste POST / PUT / DELETE sullo stesso controller per quel modello.

Se sai come parlare in REST, la vita diventa molto più semplice perché il supporto REST è già intrinsecamente inserito in qualsiasi server web (cioè HTTP è solo un tipo di API REST). Puoi anche optare per una compressione gzip trasparente se stai inviando molti dati attraverso il filo.

La mia prima impressione è che dovrebbe essere la stessa API e che la tua sicurezza dovrebbe essere su un livello completamente diverso. Forse gestito da un fronte web?