Ich stecke gerade in einem kleinen API-Design-Dilemma für unser internes Tool. Wir haben einen Endpunkt, der Kundendaten zurückgibt, und ich überlege, ob ich die Antwort wirklich flach halten soll oder ein verschachteltes Objekt mit einigen verknüpften Einträgen liefere. Ein Kollege meinte, das könnte die Performance bei vielen kleinen Clients beeinträchtigen, aber die Frontend-Entwickler würden sich über weniger einzelne Aufrufe freuen. Irgendwie fühlt sich beides halb richtig und halb falsch an. Wie habt ihr das in ähnlichen Situationen entschieden?
Aus meiner Sicht macht es Sinn die API flexibel zu gestalten statt sich sofort für flach oder verschachtelt zu entscheiden. Eine Grundstruktur mit klarer Kundendatenstruktur und dann optionale verknüpfte Daten über einen Include lässt Frontend Entwicklern Wahlfreiheit. Wenn man mehrere kleine Clients hat sollte man auf ein schlankes Payload achten und nur die Felder liefern die wirklich gebraucht werden. Kurz gesagt baut man ein Grundmodell das erweiterbar ist und benutzt eine optionale Liste statt starker Verschachtelung
Interessant dass dein Kollege Bedenken hat wegen Performance doch ich frage mich ob die Frage nicht zu simpel ist. Vielleicht ist das Problem eher wie man die API dokumentiert damit Frontend Teams wissen was optional vorhanden ist. Eine verschachtelte Struktur kann zu N zu N Verbindungen führen und macht das Caching schwerer und erhöht die Komplexität. Man könnte statt einer Entscheidung auch zwei Endpunkte anbieten einen flachen Kern und einen detaillierten Detail Endpunkt
Im Alltag sehe ich oft dass Frontend Teams lieber wenige Requests wollen und trotzdem relevante Verknüpfungen brauchen. Die Balance liegt in sparsamen Feldern in der Basis Antwort und in klaren Hinweisen wie man weitere Daten gezielt nachlädt. GraphQL könnte hier als denkbares Muster dienen aber das ist nicht immer praktikabel. Prinzipiell hilft eine Feldauswahl oder eine Metadata Planung und ein fetch policy caching damit jeder Partner die passende Menge lädt. API Design wird so zu einer Frage der Architektur statt einer einzigen Entscheidung
Vielleicht lohnt es sich die Fragestellung neu zu rahmen statt sie zu beantworten. Wenn wir Kundendaten betrachten sind Beziehungen oft wichtiger als das flache Format bleiben wir offen für verknüpfte Modelle und prüfen welche Daten wirklich variieren. Der Gedanke dass weniger Aufrufe immer besser ist wirkt verlockend doch manchmal ist die Konsistenz wichtiger als Leistung. Wozu dient das Endziel hier wirklich
