Architettura API interna ed esterna

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

Sebbene io sia d'accordo con Aneurysm9 a volte non vuoi esporre tutte le funzionalità del tuo sistema. In questo caso, è preferibile avere due API ... MA se lo fai, scegli in questo modo ... assicurati che tutte le funzionalità comuni condividano la stessa API, ovvero che sia una versione estesa di l'altro rispetto a due distinti insiemi di codice.

In questo modo puoi utilizzare il tuo per te mentre lavori per far progredire il lavoro privato, sensibile e sperimentale, pur continuando a consentire la pubblicazione e l'utilizzo di nuovi contenuti senza modificare troppo l'API pubblica.

L'ho incontrato prima (molte volte) e quello che ho finito per fare è preferibile:

Porta la BL fuori dal sito web. Rendi il sito Web un consumatore dell'API. Tratta il sito come solo un altro client della tua API. La tua API è il servizio.

Se pensi di aver bisogno di metodi API speciali solo per il sito web, ripensaci! Se è buono per l'oca, è buono per il papero. Se davvero hai davvero bisogno di funzionalità speciali per il sito web, ti suggerirei che ciò che hai veramente 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 sei convinto?

Porta il paradigma un ulteriore passo avanti ...

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

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

Stessa cosa!

Estendilo a tablet, TV, altre piattaforme telefoniche, plug-in, app di terze parti, mashup, ...

Un sacco di diverse esperienze utente tutte collegate a un'API comune.

La tua app è l'API. Il sito web è solo un client (di molti)

Utilizza un'API

Se stai implementando l'API del servizio come livello REST, aggiungi l'autenticazione ai percorsi protetti.

Probabilmente vorrai usare un framework di sviluppo che non faccia troppa "magia". Qualcosa in cui puoi definire le rotte direttamente senza un sacco di reverse engineering.

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

Recentemente l'ho implementato su Google App Engine per un'API REST / Datastore e non penso che avrebbe potuto essere più semplice. I controllori sono implementati come classi e le loro successive richieste HTTP (es. GET / POST / PUT / DELETE) sono implementate come metodi di quelle 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 arrivo aggiungendo un requisito di autorizzazione 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 integrato in un webserver sempre (cioè HTTP è solo un tipo di API REST). Puoi persino optare per la compressione gzip trasparente se invii molti dati attraverso il cavo.

La mia prima impressione è che dovrebbe essere la stessa API e che la sicurezza dovrebbe essere su un livello diverso del tutto. Forse gestito da un web front?