Hallo Habr!
Wir haben die mit Spannung erwartete zweite Ausgabe von Web Development mit Node und Express .
Im Rahmen unserer Forschung zu diesem Thema haben wir einen konzeptionellen Artikel zum Entwerfen einer Web-API aus einem Modell gefunden, in dem anstelle von Datenbankschlüsseln und -werten Links zu Ressourcen verwendet werden. Original - aus dem Google Cloud-Blog, willkommen unter Katze.
Wenn wir Informationen modellieren, ist die Schlüsselfrage, wie die Beziehung und die Beziehung zwischen zwei Entitäten definiert werden. Die Beschreibung von Mustern, die in der realen Welt in Bezug auf Entitäten und ihre Beziehungen beobachtet werden, ist eine Grundidee , die zumindest bis ins antike Griechenland zurückreicht. Es spielt auch eine grundlegende Rolle in der modernen IT-Branche.
In der relationalen Datenbanktechnologie werden Beziehungen beispielsweise mithilfe eines Fremdschlüssels beschrieben - eines Werts, der in einer Zeile einer Tabelle gespeichert ist und auf eine andere Zeile verweist, entweder in einer anderen Tabelle oder in derselben Tabelle.
Ebenso wichtig ist es, Beziehungen in der API auszudrücken. In einer Einzelhandels-API können Informationsentitäten beispielsweise Kunden, Bestellungen, Katalogeinträgen, Einkaufswagen usw. entsprechen. Die Bankkonto-API beschreibt, zu welchem Kunden ein bestimmtes Konto gehört und welchem Konto jede Schuld oder jeder Kredit zugeordnet ist.
Die häufigste Methode, mit der API-Entwickler Beziehungen ausdrücken, besteht darin, Datenbankschlüssel oder Proxys für sie in den Feldern der Entitäten bereitzustellen, die diesen Schlüsseln zugeordnet sind. In mindestens einer API-Klasse (weborientiert) gibt es jedoch eine bevorzugte Alternative zu diesem Ansatz: die Verwendung von Weblinks.
Laut der Internet Engineering Task Force ( IETF) kann ein Weblink als Werkzeug zur Beschreibung der Beziehungen zwischen Seiten im Web angesehen werden. Die bekanntesten Weblinks sind solche, die auf HTML-Seiten erscheinen und in Link- oder Ankerelementen oder in HTTP-Headern eingeschlossen sind. Links können jedoch auch in API-Ressourcen angezeigt werden. Durch deren Verwendung anstelle von Fremdschlüsseln wird die Menge an Informationen, die der API-Anbieter zusätzlich dokumentieren muss und die der Benutzer studieren muss, erheblich reduziert.
Ein Link ist ein Element in einer Webressource, das einen Verweis auf eine andere Webressource sowie den Namen der Beziehung zwischen den beiden Ressourcen enthält. Ein Verweis auf eine andere Entität wird in einem speziellen Format namens "Unique Resource Identifier" (URI) geschrieben, für das es einen IETF-Standard gibt... In diesem Standard bezieht sich das Wort "Ressource" auf jede Entität, auf die ein URI verweist. Der Name des Beziehungstyps in der Verknüpfung kann mit dem Namen der Datenbankspalte identisch sein, die die Fremdschlüssel enthält, und der URI in der Verknüpfung entspricht dem Wert des Fremdschlüssels. Die nützlichsten aller URIs sind diejenigen, die mithilfe des Standard-Webprotokolls Informationen über die referenzierte Ressource bereitstellen. Diese URIs werden als "Uniform Resource Locator" (URL) bezeichnet. Die wichtigste URL für APIs ist die HTTP-URL.
Während Links in APIs nicht weit verbreitet sind, basieren einige sehr bekannte Web-APIs immer noch auf HTTP-URLs, um Beziehungen darzustellen. Dies sind beispielsweise die Google Drive-APIund die GitHub-API . Wieso ist es so? In diesem Artikel werde ich Ihnen zeigen, wie Sie die Fremdschlüssel-API in der Praxis verwenden, ihre Nachteile im Vergleich zur Verwendung von Links erläutern und wie Sie ein Design, das Fremdschlüssel verwendet, in ein Design konvertieren, in dem Links verwendet werden.
Darstellung von Beziehungen zu Fremdschlüsseln
Betrachten Sie die beliebte pädagogische Tierhandlung Anwendung. Diese Anwendung speichert Aufzeichnungen zum Verfolgen von Informationen über Haustiere und deren Besitzer. Haustiere haben Attribute wie Name, Art und Rasse. Die Besitzer haben Namen und Adressen. Jedes Haustier ist mit seinem Besitzer verwandt, und in umgekehrter Beziehung können Sie alle Haustiere eines bestimmten Besitzers finden.
In einem typischen schlüsselbasierten Design bietet die Zoohandlungs-API zwei Ressourcen, die folgendermaßen aussehen:
Die Beziehung zwischen Lassie und Joe wird folgendermaßen ausgedrückt: Nach Ansicht von Lassie hat Joe einen Namen und eine Bedeutung, die "Eigentümer" entsprechen. Die entgegengesetzte Beziehung wird nicht ausgedrückt. Der Eigentümerwert ist "98765", ein Fremdschlüssel. Dies ist wahrscheinlich der echte Fremdschlüssel der Datenbank - das heißt, wir haben es mit dem Wert des Primärschlüssels aus einer Zeile einer Datenbanktabelle zu tun. Aber selbst wenn die API-Implementierung die Schlüsselwerte geringfügig ändert, nähert sie sich in ihren Hauptmerkmalen dem Fremdschlüssel an.
Der Wert "98765" ist für den direkten Kundengebrauch nicht sehr geeignet. In den meisten Fällen muss der Client eine URL mit diesem Wert erstellen, und in der API-Dokumentation muss die Formel für diese Konvertierung beschrieben werden. In der Regel wird dazu ein URI-Muster wie folgt definiert :
/people/{person_id}
Die umgekehrte Beziehung - Haustiere gehören dem Eigentümer - kann auch durch Implementieren und Dokumentieren eines der folgenden URI-Muster für die API verfügbar gemacht werden (die Unterschiede sind nur stilistisch, nicht inhaltlich):
/pets?owner={person_id}
/people/{person_id}/pets
Auf diese Weise entworfene APIs erfordern normalerweise die Definition und Dokumentation vieler URI-Muster. Die beliebteste Sprache zum Definieren solcher Muster ist nicht die in der IETF-Spezifikation angegebene, sondern OpenAPI (früher bekannt als Swagger). Vor Version 3.0 hatte OpenAPI keine Möglichkeit anzugeben, welche Feldwerte in welche Vorlagen eingefügt werden konnten. Daher musste ein Teil der Dokumentation in natürlicher Sprache verfasst und ein Teil vom Client erraten werden. OpenAPI 3.0 führt eine neue Syntax mit dem Namen "links" ein , um dieses Problem zu beheben. Die konsistente Verwendung dieser Funktion erfordert jedoch einige Arbeit.
So häufig dieser Stil auch ist, muss der Anbieter dokumentieren und der Client muss eine erhebliche Anzahl von URI-Mustern lernen und verwenden, die in den aktuellen API-Spezifikationen nicht gut dokumentiert sind. Zum Glück gibt es eine bessere Option.
Darstellung von Beziehungen mithilfe von Links
Was wäre, wenn die oben gezeigten Ressourcen wie folgt geändert würden:
Der Hauptunterschied besteht darin, dass in diesem Fall die Werte unter Verwendung von Referenzen und nicht unter Verwendung von Fremdschlüsselwerten ausgedrückt werden. Hier werden Links in regulärem JSON im Format von Name / Wert-Paaren geschrieben (im Folgenden wird ein Abschnitt beschrieben, in dem andere Ansätze zum Schreiben von Links in JSON erläutert werden).
Beachten Sie, dass die umgekehrte Beziehung, dh vom Haustier zum Besitzer, jetzt auch explizit implementiert wird, da der Ansicht
Joel
ein Feld hinzugefügt wurde
"pets"
.
Die Änderung
"id"
zu
"self"
ist im Wesentlichen nicht notwendig oder wichtig, aber es gibt eine Vereinbarung, dass die Verwendung
"self"
Identifiziert eine Ressource, deren Attribute und Beziehungen durch andere Name / Wert-Paare im selben JSON-Objekt angegeben werden.
"self"
Ist der Name zu diesem Zweck bei der IANA registriert?
Aus Sicht der Implementierung sollte das Ersetzen aller Datenbankschlüssel durch Links recht einfach sein - der Server konvertiert alle fremden Datenbankschlüssel in URLs, sodass auf dem Client nichts getan werden muss -, aber die API selbst ist in diesem Fall erheblich vereinfacht. und die Konnektivität zwischen dem Client und dem Server fällt aus. Viele URI-Muster, die beim ersten Entwurf wichtig waren, sind nicht mehr erforderlich und können aus der API-Spezifikation und -Dokumentation entfernt werden.
Jetzt hindert nichts den Server daran, das Format neuer URLs jederzeit zu ändern, ohne die Clients zu beeinträchtigen (natürlich muss der Server weiterhin alle zuvor formulierten URLs einhalten). Die vom Server an den Client übergebene URL muss den Primärschlüssel der in der Datenbank angegebenen Entität sowie einige Routing-Informationen enthalten. Da der Client die URL jedoch einfach wiederholt, während er auf den Server antwortet, und der Client die URL nie analysieren muss, müssen Clients nicht wissen, wie die URL formatiert wird. Infolgedessen besteht eine geringere Konnektivität zwischen dem Client und dem Server. Der Server kann sogar darauf zurückgreifen, seine eigenen URLs mithilfe von base64 oder ähnlichen Codierungen zu verschleiern, wenn er Clients betonen möchte, dass sie das URL-Format nicht "erraten" oder die Bedeutung von URLs aus ihrem Format ableiten sollten.
Im vorherigen Beispiel habe ich beispielsweise die relative URI-Notation der Referenzen verwendet
/people/98765
. Vielleicht wäre der Client etwas komfortabler (obwohl der Autor bei der Formatierung dieses Beitrags nicht sehr hilfreich war), wenn ich die URI in absoluter Form ausdrücken würde, z. Haustiere.org/people/98765... Clients müssen nur die in den IETF-Spezifikationen definierten Standard-URI-Regeln kennen, um solche URIs von einem Formular in ein anderes zu konvertieren. Daher ist die Auswahl eines bestimmten Formulars für URI nicht so wichtig, wie Sie vielleicht denken. Vergleichen Sie diese Situation mit der obigen Konvertierung vom Fremdschlüssel in die URL, für die spezielle Kenntnisse der Zoohandlungs-API erforderlich waren. Relative URLs sind für Server-Implementierer etwas bequemer, wie unten erläutert, aber absolute URLs sind für die meisten Clients möglicherweise bequemer. Dies ist wahrscheinlich der Grund, warum die Google Drive- und GitHub-APIs absolute URLs verwenden.
Kurz gesagt, die Verwendung von Links anstelle von Fremdschlüsseln zum Ausdrücken von Beziehungen zwischen APIs verringert die Menge an Informationen, die ein Client wissen muss, um mit der API zu interagieren, und verringert auch die Menge an Konnektivität, die zwischen Clients und Servern auftreten kann.
Unterwasserfelsen
Hier sind einige Dinge zu beachten, bevor Sie mit der Verwendung von Links fortfahren.
Viele API-Implementierungen wurden mit Reverse-Proxys für Sicherheit, Lastausgleich und mehr bereitgestellt. Einige Proxys schreiben URLs gerne neu. Wenn die API Fremdschlüssel zur Darstellung von Beziehungen verwendet, ist die einzige Anforderungs-URL die einzige URL, die im Proxy neu geschrieben werden muss. In HTTP wird diese URL zwischen der Adressleiste (der ersten Zeile des Headers) und dem Host-Header aufgeteilt.
Eine API, die Links zum Ausdrücken von Beziehungen verwendet, enthält andere URLs in den Kopfzeilen und im Hauptteil der Anforderung und der Antwort. Diese URLs müssen ebenfalls neu geschrieben werden. Es gibt verschiedene Möglichkeiten, damit umzugehen:
- URL . URL, .
- , . , , , -, , .
- . URL; , URL , -. URL, , , , , . - (, URL, «» «»), . , URL, , URL , , , URL .
Relative URLs ohne führende Schrägstriche sind für Clients auch schwieriger zu verwenden, da sie mit einer standardisierten Bibliothek arbeiten müssen und nicht nur mit einer Verkettung von Zeichenfolgen, um diese URLs zu verarbeiten und die Basis-URL sorgfältig zu verstehen und zu speichern.
Die Verwendung einer standardisierten Bibliothek zum Umgang mit URLs ist für Kunden ohnehin eine gute Vorgehensweise, viele Kunden jedoch nicht.
Wenn Sie Links verwenden, müssen Sie möglicherweise auch Ihre API-Versionierung überprüfen. In vielen APIs ist es üblich, Versionsnummern wie folgt in die URL einzufügen:
/v1/pets/12345
/v2/pets/12345
/v1/people/98765
/v2/people/98765
Dies ist die Art der Versionierung, bei der Daten für eine bestimmte Ressource gleichzeitig in mehr als einem „Format“ angezeigt werden können. Es geht nicht um Versionen, die sich im Laufe der Zeit gegenseitig ersetzen, wenn sie anschließend bearbeitet werden.
Diese Situation ist der Möglichkeit sehr ähnlich, dasselbe Dokument in mehreren natürlichen Sprachen anzuzeigen, für die es einen Webstandard gibt;; Schade, dass es für Versionen keinen solchen Standard gibt. Indem Sie jeder Version eine eigene URL zuweisen, aktualisieren Sie jede Version auf eine voll funktionsfähige Webressource. An "versionierten URLs" dieser Art ist nichts auszusetzen, aber sie eignen sich nicht zum Ausdrücken von Links. Wenn der Client Lassie im Format Version 2 anfordert, bedeutet dies nicht, dass er auch Informationen im Format 2 über Joe, den Eigentümer von Lassie, erhalten möchte, sodass der Server nicht auswählen kann, welche Versionsnummer in den Link aufgenommen werden soll.
Möglicherweise wird Format 2 zur Beschreibung der Eigentümer nicht einmal bereitgestellt. Es macht auch keinen konzeptionellen Sinn, eine bestimmte Version der URL in Ihren Links zu verwenden - schließlich gehört Lassie nicht zu einer bestimmten Version von Joe, sondern zu Joe selbst. Selbst wenn Sie eine URL im Format / v1 / people / 98765 angeben und damit eine bestimmte Version von Joe identifizieren, müssen Sie daher auch die URL / people / 98765 angeben, um Joe selbst zu identifizieren. Dies ist die zweite Option, die Sie verwenden in Links. Eine andere Möglichkeit besteht darin, nur die URL / people / 98765 zu definieren und Clients eine bestimmte Version auswählen zu lassen, indem sie den Anforderungsheader dafür einschließen. Es gibt keinen Standard für diesen Header, aber wenn Sie ihn Accept-Version nennen, funktioniert er gut mit der Benennung von Standard-Headern.Persönlich bevorzuge ich die Verwendung eines Headers für die Versionierung und vermeide die Verwendung von Versionsnummern in der URL. Aber URLs mit Versionsnummern sind beliebt und ich implementiere oft auch den Titel. und "versionierte URLs", da es einfacher ist, beide zu implementieren, als zu argumentieren, was besser ist. Weitere Informationen zur API-Versionierung finden Sie hier Artikel .
Möglicherweise müssen Sie ohnehin einige URL-Muster dokumentieren
In den meisten Web-APIs wird vom Server eine neue Ressourcen-URL zugewiesen, wenn eine neue Ressource mithilfe der POST-Methode erstellt wird. Wenn Sie diese Methode verwenden, um Ressourcen zu erstellen und Beziehungen mithilfe von Links anzugeben, müssen Sie keine Vorlage für die URIs dieser Ressourcen veröffentlichen. Bei einigen APIs kann der Client jedoch die URL der neuen Ressource steuern. Indem Clients die Steuerung der URLs neuer Ressourcen ermöglichen, vereinfachen wir viele der API-Skriptmuster für Front-End-Entwickler erheblich und unterstützen auch Skripts, in denen die API zum Synchronisieren des Informationsmodells mit einer externen Informationsquelle verwendet wird. HTTP bietet hierfür eine spezielle Methode: PUT. PUT bedeutet "Erstellen Sie eine Ressource unter dieser URL, falls sie noch nicht vorhanden ist, und aktualisieren Sie sie, falls vorhanden."Wenn Ihre API es Clients ermöglicht, neue Entitäten mithilfe der PUT-Methode zu erstellen, sollten Sie die Regeln für die Erstellung neuer URLs dokumentieren, indem Sie möglicherweise das URI-Muster in die API-Spezifikation aufnehmen. Sie können Clients auch eine teilweise Kontrolle über die URL geben, indem Sie einen primärschlüsselähnlichen Wert in den Hauptteil oder die POST-Header aufnehmen. In diesem Fall ist das POST-URI-Muster per se nicht erforderlich, aber der Client muss das URI-Muster noch lernen, um die resultierende URI-Vorhersagbarkeit voll auszunutzen.Der Client muss jedoch noch das URI-Muster lernen, um die resultierende Vorhersagbarkeit des URI voll auszunutzen.Der Client muss jedoch noch das URI-Muster lernen, um die resultierende Vorhersagbarkeit des URI voll auszunutzen.
Ein weiterer Kontext, in dem es angemessen ist, URL-Muster zu dokumentieren, besteht darin, dass die API Clients das URL-Codieren von Anforderungen ermöglicht. Nicht jede API ermöglicht es Ihnen, Ihre Ressourcen anzufordern, aber dies kann für Clients sehr nützlich sein und es Clients natürlich ermöglichen, Anforderungen per URL zu codieren und die Ergebnisse mithilfe einer GET-Methode abzurufen. Das folgende Beispiel zeigt warum.
Im obigen Beispiel haben wir das folgende Name / Wert-Paar in Joes Ansicht aufgenommen:
"pets": "/pets?owner=/people/98765"
Der Client muss nichts über seine Struktur wissen, um diese URL verwenden zu können, außer dass sie gemäß den Standardspezifikationen geschrieben wurde. Auf diese Weise kann der Kunde über diesen Link eine Liste von Joes Haustieren abrufen, ohne eine Abfragesprache lernen zu müssen. Es ist auch nicht erforderlich, die Formate seiner URL in der API zu dokumentieren - sondern nur, wenn der Client zuerst eine GET-Anfrage an stellt
/people/98765
... Wenn zusätzlich die Möglichkeit, Anfragen zu stellen, in der Pet Store-API dokumentiert ist, kann der Client dieselbe oder eine gleichwertige Anforderungs-URL erstellen, um die Haustiere des interessierenden Eigentümers abzurufen, ohne zuerst den Eigentümer selbst zu extrahieren genug, um die URI des Besitzers zu kennen. Vielleicht noch wichtiger ist, dass der Client auch Anforderungen wie die folgenden generieren kann, die sonst nicht möglich wären: Die URI-Spezifikation beschreibt zu diesem Zweck einen Teil der HTTP-URL, der als " Anforderungskomponente " bezeichnet wird
/pets?owner=/people/98765&species=Dog
/pets?species=Dog&breed=Collie
"Ist der Teil der URL nach dem ersten"? " bis zum ersten "#". Der Stil der URI-Anforderung, den ich bevorzuge, besteht darin, immer clientspezifische Anforderungen in die URI-Anforderungskomponente einzufügen. Es ist jedoch auch akzeptabel, Client-Anforderungen in dem Teil der URL auszudrücken, der als "Pfad" bezeichnet wird Wie auch immer, Sie müssen den Clients mitteilen, wie diese URLs aufgebaut sind. Sie entwerfen und dokumentieren tatsächlich die Anforderungssprache, die für Ihre API spezifisch ist. Natürlich können Sie Clients auch erlauben, Anforderungen in den Nachrichtentext und nicht in den zu stellen URL und verwenden Sie die POST-Methode anstelle von GET. Praktische Begrenzung der URL-Größe - über 4 KByte, die Sie jedes Mal in Versuchung führen - wird empfohlen, POST für Anforderungen zu unterstützen, auch wenn Sie GET bereits unterstützen.
Da Abfragen in APIs eine so nützliche Funktion sind und Abfragesprachen nicht einfach zu entwerfen und zu implementieren sind, sind Technologien wie GraphQL entstanden . Ich habe GraphQL noch nie verwendet, daher kann ich es nicht empfehlen, aber Sie können es als Alternative für die Implementierung der Abfragefähigkeit in Ihrer API betrachten. API-Anforderungstools, einschließlich GraphQL, werden am besten als Add-On zur Standard-HTTP-API zum Lesen und Schreiben von Ressourcen und nicht als Alternative zu HTTP verwendet.
Übrigens ... Wie schreibe ich am besten Links in JSON?
JSON verfügt im Gegensatz zu HTML nicht über einen integrierten Mechanismus zum Ausdrücken von Links. Viele Menschen haben ihre eigene Art zu verstehen, wie Links in JSON ausgedrückt werden sollten, und einige dieser Meinungen wurden in mehr oder weniger offiziellen Dokumenten veröffentlicht, aber derzeit gibt es keine Standards, die von seriösen Organisationen ratifiziert wurden, die dies regeln würden. Im obigen Beispiel habe ich Links mit regulären Name / Wert-Paaren ausgedrückt, die in JSON geschrieben wurden. Ich bevorzuge diesen Stil und dieser Stil wird übrigens in Google Drive und GitHub verwendet. Ein anderer Stil, den Sie wahrscheinlich sehen werden, ist folgender:
{"self": "/pets/12345",
"name": "Lassie",
"links": [
{"rel": "owner" ,
"href": "/people/98765"
}
]
}
Persönlich sehe ich nicht, wofür dieser Stil gut ist, aber einige seiner Variationen sind sehr beliebt.
Es gibt einen anderen Stil der JSON-Referenzierung, den ich mag, und er sieht folgendermaßen aus:
{"self": "/pets/12345",
"name": "Lassie",
"owner": {"self": "/people/98765"}
}
Der Vorteil dieses Stils besteht darin, dass er explizit Folgendes angibt:
"/people/98765"
Ist eine URL, nicht nur eine Zeichenfolge. Ich habe dieses Muster von RDF / JSON gelernt . Einer der Gründe, dieses Muster zu beherrschen, besteht darin, dass Sie es trotzdem verwenden müssen, wenn Sie Informationen zu einer in einer anderen Ressource verschachtelten Ressource anzeigen möchten, wie im folgenden Beispiel gezeigt. Wenn Sie dieses Muster überall verwenden, erhält Ihr Code eine schöne Einheitlichkeit:
{"self": "/pets?owner=/people/98765",
"type": "Collection",
"contents": [
{"self": "/pets/12345",
"name": "Lassie",
"owner": {"self": "/people/98765"}
}
]
}
Weitere Informationen zur optimalen Verwendung von JSON zur Darstellung von Daten finden Sie unter Terrific Simple JSON .
Was ist schließlich der Unterschied zwischen einem Attribut und einer Beziehung?
Ich denke, die meisten Leser werden zustimmen, dass JSON keinen eingebauten Mechanismus zum Ausdrücken von Links hat, aber es gibt auch eine Möglichkeit, JSON zu interpretieren, mit der Sie anders argumentieren können. Betrachten Sie den folgenden JSON:
{"self": "/people/98765",
"shoeSize": 10
}
Es ist allgemein anerkannt, dass es sich
shoeSize
um ein Attribut handelt, nicht um eine Beziehung, und 10 ist ein Wert, keine Entität. Es ist zwar nicht weniger logisch zu behaupten, dass die Zeichenfolge '10 "tatsächlich eine Referenz ist, die in einer speziellen Notation geschrieben ist, die sich auf Zahlen bezieht, bis zur 11. Ganzzahl, die selbst eine Entität ist. Wenn die 11. Ganzzahl eine vollkommen gültige Entität ist und die Zeichenfolge
'10'
nur darauf zeigt, ist das Name / Wert-Paar
'"shoeSize": 10'
konzeptionell eine Referenz, obwohl URIs hier nicht verwendet werden.
Das Gleiche gilt für Boolesche Werte und Zeichenfolgen, sodass alle Name / Wert-Paare in JSON als Referenzen behandelt werden können. Wenn Sie diese Art des Denkens über JSON denken, ist es natürlich, einfache Name / Wert-Paare in JSON als Verweise auf Entitäten zu verwenden, auf die auch mithilfe einer URL verwiesen werden kann.
Allgemeiner wird dieses Argument wie folgt formuliert: "Es gibt keinen grundlegenden Unterschied zwischen Attributen und Beziehungen." Attribute sind einfach Beziehungen zwischen einer Entität oder einer anderen abstrakten oder konkreten Entität, z. B. einer Zahl oder Farbe. Historisch gesehen wurde ihre Verarbeitung jedoch auf besondere Weise behandelt. Ehrlich gesagt ist dies eine ziemlich abstrakte Version der Wahrnehmung der Welt. Wenn Sie also jemandem eine schwarze Katze zeigen und fragen, wie viele Objekte es gibt, werden die meisten Leute Ihnen sagen, dass es nur eines gibt. Nur wenige würden sagen, dass sie zwei Objekte sehen - eine Katze und ihre schwarze Farbe - und die Beziehung zwischen ihnen.
Links sind einfach besser
Web-APIs, die Datenbankschlüssel und nicht nur Links übergeben, sind schwieriger zu erlernen und auch für Clients schwieriger zu verwenden. Auch APIs der ersten Art verbinden den Client und den Server enger miteinander und erfordern detailliertere Informationen als "gemeinsamen Nenner". Alle diese Informationen müssen dokumentiert und gelesen werden. Der einzige Vorteil von APIs der ersten Art ist, dass sie so allgegenwärtig sind, dass Programmierer mit ihnen vertraut sind, wissen, wie man sie erstellt und wie man sie verwendet. Wenn Sie Kunden hochwertige APIs bereitstellen möchten, für die nicht viel Dokumentation erforderlich ist, und die Unabhängigkeit der Clients vom Server maximieren möchten, sollten Sie Links zu Ihren Web-APIs anstelle von Datenbankschlüsseln bereitstellen.