Frage

Wir haben ein B2B-Web-Portal für Graphics Job Arbeit entwickelt, die auf die Kamera bereit Kunst (www.camerareadyart.com) ähnlich ist. Es ist für Menschen gezielt zu wollen Bitmap-Vektor-Grafiken, Logo Design und die allgemeinen Bildverarbeitung wie Färbung B / W Bilder zu Farbe konvertieren, etc.

Wir wollen Anlage hinzufügen, so dass die Menschen (unsere Kunden) eine Reihe von API verwenden können, dass wir ihre Arbeit von ihrer Website direkt ohne unsere Website besuchen zu müssen, um Posten bieten buchstäblich ihre Arbeit zu veröffentlichen.

Ich habe noch nie so etwas bis heute getan, so habe ich keine Ideen, wie ich so etwas wie dies umsetzen kann. Ich möchte auch wissen, wie wir die Sicherheit implementieren können, so dass nur diejenigen, die autorisiert sind, können ihre Arbeit schreiben?

Kann jemand geben Sie mir Ideen, wie wir etwas tun können.

War es hilfreich?

Lösung

Diese Frage umfasst einen sehr großen Bereich und ich bezweifle, jede einzelne Antwort Fragen im Detail abdecken könnte. Was ich tun kann, ist, einige Ansatzpunkte bieten, basierend auf dem Fehler, die ich gemacht habe.

Erstellen Sie auf Ihre eigene API
Nicht-Add-In-API-Funktionen zu einem bestehenden System. Dabei werden:

  • führen zu weiteren Tests unterzogen Last (Sie werden sowohl Ihre Anwendung und die API zu testen, haben unabhängig)
  • führt zu einer Erhöhung der Gesamtwartungskosten
  • Ergebnis in einer schlechteren Qualität API als das, was Sie wollen, bieten

Sie sollte übergeordnetes Ziel, die API zuerst zu bauen und dann die App auf Ihre eigene API zu bauen. so hat die folgenden Vorteile zu tun:

  • Prüfung der API von Natur aus durchgeführt wird, während das Testen Ihrer App
  • Sie werden nicht ‚vergessen‘ alle erforderlichen API-Methoden hinzufügen

Ihre Anwendung und Anwendungslogik (die API) wird logisch getrennt werden - wird es eine klare Trennung zwischen ihnen in Bezug auf das, was jede Seite der Gleichung tut und was es ist verantwortlich für. Dies wird Führungs Entwicklung helfen. Dies wird Ihnen auch ermöglichen, sehr, sehr leicht die App setzen und die API auf verschiedenen Maschinen, wie und wann diese benötigt wird.

Ihre eigene API zu verwenden ist ein sehr wichtiger Punkt. Das Design Ihrer API wird zunächst suboptimal sein und nur durch sie mit sich selbst werden Sie in der Lage sein, um es die Eigenschaften, um die Menschen zu bieten, die in einer Art und Weise tatsächlich benötigt werden, die effizient ist.

Sie werden mit einem System am Ende, die in etwa wie folgt aussieht:

-------------                          -------------
|           |                          |           |
| Your APP  | <= HTTP communication => | Your API  |
|           |                          |           |
-------------                          -------------

Dies zeigt einige weitere Vorteile: Sie können mit einer anderen App ‚Ihre APP‘ ersetzen, so dass Kunden von Ihnen Anwendungen erstellen mit den Dingen in einer Weise zu behandeln, die mit ihnen am besten funktionieren. Sie können auch neue Versionen Ihrer App auf der bestehenden API erstellen -. Auf eine neue Version Ihrer öffentlichen Website bewegen kann viel einfacher sein

Entwerfen Sie Ihre URLs: Zuordnung zu Klassen und Methoden
vernünftigen URLs Der Wahl ist so viel von einem Problem als fühlbare Klassen- und Methodennamen wählen. URLs von Klassen und die Methoden ergibt, ist ein guter Ansatz. Wenn es keine sinnvolle Korrelation zwischen URLs und Klassen / Methoden ist, werden Sie die Sache schwieriger finden auf lange Sicht zu erhalten.

Ich persönlich bevor URLs zu Klassen und Methoden in folgenden Weise zu verknüpfen:

  • Karte Klassen Verzeichnisse der obersten Ebene
  • Karte Methoden Unterverzeichnisse der Top-Level-Verzeichnisse

Beispiel:
Die URL Ihrer API ist https://api.camerareadyart.com .
Sie haben ein image Objekt mit toColour() und toBlackAndWhite() Methoden.

Dies kann Karte an:

https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/

Ebenso für Bitmap-Vektor Konvertierung:

https://api.camerareadyart.com/bitmap/toVector/

Designing Antworten
Wenn jemand GETs Daten aus, oder POSTs Daten an, einer Ihrer URLs, was passiert? Wie werden Fehler behandelt, wie geht es Ausnahmen umgegangen? Welche Form nehmen Antworten?

Ich kann Ihnen nicht sagen, was hier zu tun. Persönlich bevorzuge ich die Dinge abzubilden so nah zu HTTP wie möglich und dann nur darüber hinausgehen, wenn nötig.

Zum Beispiel, wenn eine eingehende Anforderung akzeptiert und verarbeitet wird, läuft aber in einen Fehler intern würde ich eine 500 Statusantwort erteilen. Ebenso, wenn eine bestimmte API-Methode eine Authentifizierung erforderlich ist, die bereitgestellt wurde nicht könnte ich einen 403. Unter Ausnutzung der bestehenden HTTP-Funktionen Ausgabe verhindert, dass Sie mit bestimmten Dingen neu zu erfinden.

Verwenden bestehende Aspekte der HTTP
Neben der Verwendung sinnvoll Codes HTTP-Status, stellen Sie sicher, für eine HTTP-Methode nur um sich umzusehen, etwas zu tun, bevor Sie Ihre eigene Lösung rollen.

Möchten Sie die Benutzer angeben, ob das Antwortformat sollte von XML oder JSON? Verwenden Sie die HTTP-Accept-Header.

Möchten Sie einen Client auf eine andere umzuleiten das Ergebnis einer Anfrage zu greifen? Verwendendie HTTP-Location-Header.

Es gibt viele Funktionen HTTP, die bereits viele Dinge behandeln Sie tun möchten. Verwenden Sie sie!

Sicherheit
Es gibt zwei allgemeine Probleme hier in Angriff zu nehmen. Authentifizierung des Benutzers, und bestimmen, welche Aktionen ein bestimmter Benutzer ausführen können,

Sicherheit: Authentifizierung
Der Benutzer muss in ihrem Antrag angeben, wer sie sind.

Die erste Lösung in den Sinn Frühling ist, damit der Benutzer einen Benutzernamen und ein Passwort angeben, möglicherweise der gleiche wie der Benutzername und das Passwort verwenden sie Ihre App zugreifen. Dies scheint auf der Oberfläche eine gute Idee zu sein, aber es ist nicht ideal.

Die Benutzer ihren Benutzernamen und das Passwort in die eigenen Anwendungen am Ende backen. Zwangsläufig ein Benutzer sein Passwort vergessen, und wird es so ändern, dass sie glücklich Ihre App zugreifen können, um ihre eigenen App im Prozess zu brechen.

Eine bessere Wahl wäre für den Benutzer, eine Authentifizierungs-Token zu liefern, die im Wesentlichen einzigartig ein einzelner Wert ist, für einen Benutzer wie ein Benutzername und das Passwort in eine.

So können Sie logisch einen Benutzernamen und ein Passwort aus Zugriff auf die API trennen. Ein Benutzer kann seinen Benutzernamen und / oder Passwort für Ihre Anwendung so oft wie sie, ohne zu brechen, um die API ihren Zugang gerne ändern.

Ein Benutzer kann auch mehrere API-Token hat, die jeweils mit unterschiedlichen Zugriffsebenen, so dass ein Benutzer sicher ein API-Token zu einem Dritt Service geben.

Sicherheit: Zugangskontrolle
Soweit die Außenwelt betrifft, Ihre API ist eine Reihe von URLs. Jede URL ist per definitionem einzigartig und führt eine einzigartige Aufgabe. Gründend Ihre Zugriffskontrollmechanismen um diese Konzepte ist ein guter Ausgangspunkt.

Ich ziehe eine Liste zu halten, pro Chip, der URLs, die für den Zugriff erlaubt ist Token. Wenn ein gegebenes Token eine URL zugegriffen wird es trivial ist zu sagen, welche URL zugegriffen wird und ob es in der Liste der Token des erlaubten URLs.

Wenn Sie eine Reihe von URLs mit Bedacht wählen, wobei jede URL eine einmalige Aktion ausführt, dieser Prozess liefert Ihnen über die feinsten Ebene der Zugriffskontrolle, wie du gehst zu erhalten.

ein feineres Maß an Kontrolle Damit Sie auch angeben möchten, per URL, die ein Zeichen für den Zugriff erlaubt ist, was query Argumente, die sie verwenden dürfen.

Andere Tipps

Sie müssen natürlich Ihren Backend-Web Service entwickelt haben und arbeiten. Allerdings werden alle zusätzlichen Funktionen (Sicherheit, Drosselung, OAuth Schlüssel-Management, Teilnehmer-Portal, interaktive Konsole die APIs, um zu versuchen, etc.) sind ein ziemlich Standard-Satz von Funktionen, die Sie sollten wahrscheinlich nicht selbst entwickeln werden.

Es gibt kommerzielle API-Management-Lösungen auf dem Markt. Ich arbeite für WSO2, die ein 100% Open Source (Apache License) WSO2 API-Manager hat, dass Sie frei hier oder verwenden Sie als Cloud-gehostete Version in WSO2 API Wolke .

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top