2009-10-13 5 views
12

Viele Websites verfügen heute über APIs, mit denen Benutzer Daten von der Site als XML oder JSON mithilfe einer GET HTTP-Anforderung abrufen können. Flickr und del.icio.us sind Beispiele für Websites mit APIs. Diese APIs erfordern, dass der Server auf die Datenbank zugreift und das Ergebnis dann als XML oder JSON ausgibt.Warum sollte ich Außenstehenden keinen Zugang zu meiner Datenbank geben?

Warum brauchen wir diese Übersetzung? Warum erstellen Sie nicht einfach einen Benutzer in der Datenbank (zum Beispiel MySQL)? Der Benutzer würde begrenzten Zugriff auf die Datenbank erhalten und nur SELECT und nur bestimmte Tabellen und bestimmte Spalten in diesen Tabellen. Wäre das nicht viel effizienter für den Server (es müsste sich nicht mit der HTTP-Anfrage befassen), und es wäre für Entwickler einfacher, die jetzt genau auf die Daten zugreifen könnten, die sie brauchen, so wie sie es brauchen.

+9

Geben Sie * mir * Zugriff auf Ihre Datenbank, und ich zeige * Ihnen * warum sollten Sie keinen Außenseitern Zugriff auf Ihre Datenbank geben. – MusiGenesis

Antwort

32

Sicherheitsaspekte beiseite, so dass Sie Ihre Datenbankstruktur ändern können, ohne Ihre Kunden zu beeinträchtigen. Auch schlecht gebildete Abfragen binden Ihren Server, nicht die Clients.

+4

Oh, guter Punkt. Die Abstraktionsebene, um Ihnen Flexibilität zu geben, ist enorm. –

28

Können Sie verhindern, dass eine böswillige Person eine superkomplexe SQL-Abfrage erstellt, die die CPU Ihrer Datenbank zu 100% bindet? Kannst du verhindern, dass viele unschuldige Programmierer ineffiziente Abfragen erstellen, die niemals optimiert werden und dasselbe tun?

+1

Sind keine Tools verfügbar, um ein Timeout für ein SQL-Skript festzulegen? – Marius

+1

Sicher. Aber Abfragen kommen asynchron, und bis Sie die Zeitüberschreitung erreicht haben, wird die Datenbank (fast immer Ihr Flaschenhals auch ohne dieses Schema) immer noch eine Menge CPU-Zyklen machen. Es ist mir egal, wie kurz du das Timeout einstellst, ich kann es ausnutzen. –

+1

Und selbst das deckt die Probleme nicht ab, die alle anderen aufgeworfen haben: kein Caching, keine Skalierung, keine Flexibilität, keine Möglichkeit, Schemas zu ändern, keine Portabilität. Die Gründe dafür sind zahllos. Es ist eine gute Frage, und ich verstehe, warum jemand kurz darüber nachdenken könnte, aber niemand sollte es jemals mit etwas versuchen, das ihnen wichtig ist. Versuchen Sie als Experiment, eine Datenbank mit einem Sperrbenutzer auf einer virtuellen Maschine nach draußen zu bringen. Lade die Leute ein, damit herumzuspielen. Ich werde betäubt sein, wenn es eine Stunde dauert. –

2

Der Webserver gibt Ihnen einen Puffer, den Sie steuern können. Wenn es einen Fehler in Ihrem SQL-Server oder was auch immer gibt, möchten Sie nicht, dass es direkt im Internet verfügbar gemacht wird. stimmt, wenn der Webserver Fehler hat, könnte es genauso schlimm sein ... außer dass Sie diese zusätzliche Ebene zwischen den Daten und der Welt haben.

-don

3

Portabilität zu. Sagen wir aus Lizenzgründen und Skalierung, dass Sie die Geschäftsentscheidung treffen, von MSSQL nach MySql zu wechseln. Syntax ist nicht ganz gleich und Ihre Kunden müssen ihren Code ändern.

Viel besser, nur alles abzupuffern und die Implementierung abstrahiert zu halten. Wessen Aussage, dass Sie den Status der Anwendung nicht beibehalten, indem Sie trainierte Affen verwenden, die an Flaschenröhrchen kratzen?

1

Es ist nicht so sehr ein 'warum nicht' als ein 'warum sollten Sie' in Frage stellen. Die Verarbeitung von HTTP-Anfragen ist eine kleine Strafe für die vollständige Kontrolle darüber, was für alle Daten Sie zulassen oder welchen Benutzern der Zugriff verweigert wird. Sollte sich die Art/Menge/Sicherheitsstufe der Daten in der Zukunft ändern, ist eine JSON/XML-Antwort besser, als einen vollständigen Zugriff zuzulassen.

11

Eine API:

  • Erleichtert Nutzung montior und Kontrolle (‚begrenzte Anfragen pro X‘ für DB-Benutzer Umsetzung schwieriger sein kann)
  • Ermöglicht dem Anwender einfachere Strukturen präsentieren als sein kann in der DB verwendet.
  • Bedeutet, dass der Benutzer Ihre DB-Struktur nicht verstehen muss.
  • Ermöglicht DB-Portabilität. (Oh, du bist massiv gewachsen und musst jetzt implementieren: sharding, migrieren zu bigtable usw. - Mit einer API muss der Benutzer nichts wissen)
  • Ermöglicht das (andere/bessere?) Zwischenspeichern von Anfragen .
  • Bedeutet, dass Sie nicht für zusätzliche DB-Benutzer bezahlen müssen (wenn die DB so lizenziert ist.
  • )
10

Coding Vertrag - mit APIs, können Sie alles hinter sich ändern, ohne dass Außenstehende zu beeinflussen von ihnen. Hier binden Sie sie nicht nur an MySQL, sondern auch an Ihr Schema

Caching - Wenn Sie ihnen eine Abfrage erlauben, wird fast jede Gelegenheit zum Zwischenspeichern dieser vorhersagbaren Abfragen über http, die verwendet werden kann, entfernt. Dies ist wahrscheinlich der beste Weg, den oft größten Flaschenhals, die Datenbank, zu entfernen.

Sicherheit - mit diesem Ansatz wäre es leicht für einen Denial-of-Service-Angriff, auch durch Zufall. Ganz zu schweigen von der Tatsache, dass Sie Zugang zur Datenschicht geben müssen, die oft in eine eingeschränkte Zone gesetzt wird, in der die Sicherheit verschärft werden kann

Benutzerfreundlichkeit - nicht jeder ist ein Entwickler oder möchte eine Ihre interne Domäne verstehen . Sie bevorzugen wahrscheinlich eine vorgefertigte, geradlinige und selbsterklärende API. Ein extremes Beispiel wäre, den Managern db-Privilegien und keine Berichte zu geben.

0

API ist eine Art Wrapper rund um die Datenbank. Benutzer wissen nichts über die datenbankinterne Darstellung von Daten, er muss nur eine Anzahl von vereinheitlichten Anfragen senden und erhält eine einheitliche Antwort darauf. Wie und wann Daten auf dem Server verarbeitet werden - es sind nicht seine Kopfschmerzen.

3

Sicherheit ist der Grund Nummer 1, aber ich hoffe, dass diese Gründe offensichtlich sind. Der Benutzer, der wertvolle Ressourcen mit schlechten Abfragen bindet, ist ein weiterer guter Grund.

Darüber hinaus, warum eine Abstraktionsschicht?

  • Vielleicht möchten Sie Datenbankabfragen ein wenig Protokollierung hinzufügen, um die Geschwindigkeit zu diagnostizieren oder das Debuggen zu erleichtern?
  • Könnten Sie jemals von MySQL zu MS SQL wechseln oder umgekehrt, wo SQL anders als reines ANSI brechen könnte?
  • Soll der Kunde wirklich Ihr Schema lernen, anstatt eine logischere Abstraktion?
  • Wenn ein neuer Programmierer von Normalisierung lernt und nun Ihr ganzes Schema einschließlich Ihrer sorgfältig ausbalancierten Denormalisierungen sehen kann, wollen Sie jede uninformierte Kritik ertragen?
  • Wenn ein erfahrener db-Mitarbeiter auf Verbesserungen hinweist, möchten Sie mit Ihrem alten Schema festgefahren sein?
  • Warum eine API zu verwenden ist eine Frage warum man Abstraktionen benutzt und meine Liste hier kratzt kaum die Oberfläche.

    1

    Die Sache zu bedenken, wenn Sie an Sicherheitsprobleme denken ist, dass es wirklich schwer ist, alle möglichen Vektoren vorwegzunehmen, die jemand verwenden könnte, um Sie anzugreifen. Zum Beispiel, sind Sie wirklich sicher Sie haben Ihre Datenbank Berechtigungen gesetzt, so dass die Leute nicht Dinge durcheinander bringen können?

    Daher möchten Sie versuchen, Aktionen nur auf das zu beschränken, von dem Sie wissen, dass es gut ist, und nicht nur versucht, die Dinge einzuschränken, von denen Sie wissen, dass sie schlecht sind. Dies kann mit einem Webdienst geschehen, über den Sie absolute Kontrolle haben, aber es ist schwierig, jemandem den direkten Zugriff auf die Datenbank zu erlauben und sicherzustellen, dass Sie sicher sind.

    +0

    Und sind Sie wirklich sicher, dass Ihr RDBMS fehlerfrei ist und dass * keine * Fehler bei der Benutzererweiterung im SQL-Parser vorhanden sind? Wenn es einen solchen Fehler gibt, ist das ziemlich katastrophal ("ooo lookie: Ich kann DROP DATABASE master machen!"). Eine einfache, gut gestaltete API kann eine zusätzliche Barriere darstellen (immer noch möglich, wenn Sie Ihre API fehlerhaft oder schlecht entwerfen). –

    Verwandte Themen