REST API Design pro Entität

Question

Sollten wir einen REST-API-Endpunkt pro Entität haben? Zum Beispiel haben wir Mitarbeiter und er hat Büroadresse, persönliche Adresse, eine andere Adresse. Wenn Verbraucher nach Mitarbeiterdetails fragen, sollten wir nur "firstName, lastName und IDs der Adresse" zurückgeben und der Verbraucher eine weitere Abfrage nach Adressobjekten auslösen. Wie wählen wir welchen Ansatz und welche Richtlinien helfen, solche Entscheidungen zu treffen?

Answer 1

Sollten wir einen REST-API-Endpunkt pro Einheit haben?

Es gibt keine universellen Regeln in der Welt. Programmierung ist nur eine halbe Wissenschaft. Es ist eine Kunst für eine andere Hälfte. Sie entscheiden, was Sie wählen sollen. Und wir können Sie nicht beraten, ohne Ihren Kontext zu kennen.

Zum Beispiel haben wir Mitarbeiter und er hat Büroadresse, persönliche Adresse, einige andere Adresse. Wenn Verbraucher für Mitarbeiter Details anfordern, sollten wir nur "firstName, lastName und IDs der Adresse" und Verbraucher eine weitere Abfrage für Adressobjekte auslösen.Wie wählen wir welchen Ansatz und was sind die Richtlinien, die dazu beitragen, solche Entscheidung zu machen.

Versuchen Sie zu sehen, wie es in Facebook Graph API implementiert ist. In wenigen Worten: Verwenden Sie einfach einen Abfrageparameter, der eine Liste von Feldern/abhängigen Objekten darstellt, die im Ergebnis enthalten sein müssen.

Answer 2

Sollten wir einen REST-API-Endpunkt pro Einheit haben?

"Die REST-Schnittstelle hat in der Regel sehr viel mehr Ressourcen als Domänenobjekte in Ihrem Kerndomänenmodell." - Jim Webber (2011)

Wenn Verbraucher nach Mitarbeiterdetails fragen, sollten wir nur "firstName, lastName und IDs der Adresse" zurückgeben und Verbraucher eine weitere Abfrage für Adressobjekte auslösen. Wie wählen wir welchen Ansatz und welche Richtlinien helfen, solche Entscheidungen zu treffen?

Es ist nützlich zu wissen, wie das Web funktionieren soll. Fielding beschreibt viele der Probleme, die Web-Architektur entworfen wurde, in chapter 4 of his thesis zu lösen:

Hypermedia durch das Vorhandensein von Anwendungssteuerungsinformationen definiert ist, eingebettet, oder als Schicht über die Präsentation von Informationen. Verteilte Hypermedien ermöglichen die Speicherung der Darstellungs- und Steuerinformationen an entfernten Standorten. Von Natur aus erfordern Benutzeraktionen innerhalb eines verteilten Hypermedia-Systems die Übertragung großer Datenmengen von dem Ort, an dem die Daten gespeichert sind, zu dem Ort, an dem sie verwendet werden. Daher muss die Web-Architektur für eine Übertragung großer Datenmengen ausgelegt sein.

Mit anderen Worten, Caching ist ein wesentliches Anliegen, wenn man sich Web-Skala gehen zu arbeiten.

Wenn Mitarbeiterdetails stabil sind, dann ist es großartig, alle in ein langlebiges Dokument zu werfen - dieses Dokument kann viele Anfragen für eine lange Zeit erfüllen. Auf der anderen Seite sehen alle Clients, die mit einer zwischengespeicherten Kopie des Dokuments arbeiten, nicht die letzten Änderungen - flüchtige Daten möchten normalerweise unterschiedliche Caching-Regeln von stabilen Daten haben.

Feinkörnige Ressourcen sind tendenziell leichter zu bearbeiten - in HTTP ersetzt PUT den Status einer Ressource. Kleinere Ressourcen bedeuten weniger Daten für den Kunden und weniger Kollisionsgefahr mit anderen Bearbeitungen.