Interne und externe API-Architektur

Das Unternehmen, für das ich arbeite, unterhält ein erfolgreiches SaaS-Produkt, das im Laufe der Jahre "organisch" gewachsen ist. Wir planen, die Produktreihe um eine Reihe neuer Produkte zu erweitern, die Daten mit dem vorhandenen Produkt teilen. Um dies zu unterstützen, möchten wir die Geschäftslogik an einem einzigen Ort konsolidieren: einer Webserviceschicht. Die WS-Schicht wird verwendet von:

• Die Webanwendungen
• Ein Tool zum Importieren von Daten
• Ein Tool zur Integration in andere Client-Software (keine API per se)

Wir möchten auch eine API erstellen, die von unseren Kunden verwendet werden kann und die in der Lage ist, eigene Integrationen zu erstellen. Wir haben mit der folgenden Frage zu kämpfen:

Sollte die interne API (auch als WS-Schicht bezeichnet) und die externe API identisch sein, mit Sicherheits- und Berechtigungseinstellungen, um zu steuern, was von wem getan werden kann, oder sollten es zwei separate Anwendungen sein, bei denen die externe API nur die interne API aufruft wie jede andere Anwendung? Bisher scheint es in unserer Debatte sicherer zu sein, sie zu trennen, aber das wird den Aufwand erhöhen.

Was haben andere in einer ähnlichen Situation getan?

Es ist immer gut, sein eigenes Hundefutter zu essen. Eine API sollte auch einfacher zu warten sein als zwei, selbst wenn Sie einen gewissen Aufwand für die Authentifizierung und Autorisierung einkalkulieren.

Obwohl ich mit Aneurysm9 einverstanden bin, möchten Sie manchmal nicht alle Funktionen Ihres Systems offenlegen. In diesem Fall sind zwei APIs vorzuziehen ... ABER wenn Sie dies so gewählt haben ... stellen Sie sicher, dass alle gängigen Funktionen dieselbe API verwenden, dh dass eine erweiterte Version der anderen ist und nicht zwei unterschiedliche Sätze von Code.

Auf diese Weise können Sie Ihre eigenen verwenden, während Sie einen Platz für private, sensible, experimentelle Arbeiten haben, während Sie weiterhin die Möglichkeit haben, die neuen Inhalte zu veröffentlichen und zu verwenden, ohne die öffentliche API zu stark zu ändern.

Das habe ich (schon oft) erlebt und am Ende habe ich Folgendes bevorzugt:

Nehmen Sie die BL aus der Website. Machen Sie die Website zu einem Verbraucher der API. Behandeln Sie die Website wie einen anderen Client Ihrer API. Ihre API ist der Dienst.

Wenn Sie der Meinung sind, dass Sie spezielle API-Methoden nur für die Website benötigen, überlegen Sie es sich noch einmal! Wenn es gut für die Gans ist, ist es gut für den Betrachter. Wenn Sie wirklich, wirklich, wirklich spezielle Funktionen für die Website benötigen, würde ich vorschlagen, dass Sie tatsächlich einen Unterschied im "Benutzerprofil" festgestellt haben. Daher sollte die API die "speziellen" Funktionen weiterhin unterstützen, aber Sie steuern sie über die Autorisierung.

Nicht überzeugt?

Nehmen Sie das Paradigma einen Schritt weiter ...

Die Telefon-App wird auf einer Plattform ausgeführt, auf der Bytecode ausgeführt wird, die App im Telefon gespeichert ist und API-Dienste über HTTP / JSON verwendet

Die Website ist eine App, die auf einer Plattform ausgeführt wird, auf der HTML + Javascript ausgeführt wird, die App im Browser ausgeführt wird und API-Dienste über HTTP / JSON verwendet

Gleich!

Erweitern Sie das auf Tablets, Fernseher, andere Telefonplattformen, Plugins, Apps von Drittanbietern, Mashups, ...

Viele verschiedene Benutzererfahrungen sind alle mit einer gemeinsamen API verbunden.

Ihre App ist die API. Die Website ist nur ein Kunde (von vielen)

Verwenden Sie eine API

Wenn Sie die Service-API als REST-Schicht implementieren, fügen Sie den geschützten Routen lediglich eine Authentifizierung hinzu.

Sie werden wahrscheinlich ein Entwicklungsframework verwenden wollen, das nicht zu viel "Magie" enthält. Etwas, bei dem Sie Routen ohne viel Reverse Engineering direkt definieren können.

Denken Sie an etwas wie Node.js / Express, Python / Pylons, Python / Google App Engine usw.

Ich habe dies kürzlich in Google App Engine für eine REST / Datastore-API implementiert und glaube nicht, dass es einfacher hätte sein können. Controller werden als Klassen implementiert, und ihre nachfolgenden HTTP-Anforderungen (dh GET / POST / PUT / DELETE) werden als Methoden dieser Klassen implementiert. Ich habe es geschafft, basic-auth als Dekorateur zu implementieren. Dies machte das Hinzufügen einer Authentifizierungsanforderung zu einer Anfrage so einfach wie das Anhängen des @ basicAuth-Dekorators.

Auf diese Weise könnte ich eingehende GET-Anforderungen öffentlich machen und POST / PUT / DELETE-Anforderungen auf demselben Controller für dieses Modell eine Authentifizierungsanforderung hinzufügen.

Wenn Sie wissen, wie man in REST spricht, wird das Leben viel einfacher, da die REST-Unterstützung bereits in einen Webserver integriert ist (dh HTTP ist nur eine Art REST-API). Sie können sich sogar für eine transparente gzip-Komprimierung entscheiden, wenn Sie viele Daten über die Leitung senden.

Mein erster Eindruck ist, dass es sich um dieselbe API handeln sollte und dass sich Ihre Sicherheit insgesamt auf einer anderen Ebene befinden sollte. Vielleicht von einer Webfront gehandhabt?