Trumpft die Entkopplung bei REST die TROCKENE?

Ich erstelle eine REST-API, um den größten Teil der Funktionalität einer vorhandenen Java-API verfügbar zu machen. Beide APIs sind für die interne Verwendung in meiner Organisation vorgesehen. Ich muss nicht für den externen Gebrauch designen. Ich habe Einfluss auf beide APIs, implementiere aber die REST-API. Die Java-API wird weiterhin für lokale Anwendungen verwendet (sie wird nicht "zurückgezogen"), die REST-API wird jedoch für wichtige Neuentwicklungen verwendet.

Einige der Java-API-Klassen sind einfach Daten (Beans mit Eigenschaften, Gettern, Setzern). Zumindest einige davon sind sinnvoll (in irgendeiner Form) über die REST-API als Daten zu übertragen (die in XML oder JSON zusammengefasst werden). Beispiel: Eine Klasse, die Informationen zu einem Servercomputer speichert. Ich stehe für diese Datenklassen vor der folgenden Wahl: Muss ich ...

1. Machen Sie die ursprüngliche Java-Klasse (oder eine Unterklasse) direkt in der REST-API verfügbar
2. Neue Datenübertragungsklasse (DTO-Muster) speziell für die REST-API erstellen?

In beiden Fällen wird es REST-Datenübertragungsklassen geben. Die Frage ist, ob die Originale mit Anmerkungen versehen oder neue erstellt werden sollen (möglicherweise in der Nähe von Kopien der Originale). Es mag andere Möglichkeiten geben, aber ich werde mich hauptsächlich auf diese beiden konzentrieren.

Argumente für # 1:

• DRY (wiederhole dich nicht)
• Schneller zu implementieren
• Einfacheres Upgrade der REST-API

Argumente für # 2:

• Was ist, wenn die REST-API separat von der Java-API versioniert werden muss? (Dies ist etwas wahrscheinlich.)
• Was ist, wenn sich an den Java-Datenklassen wesentliche Änderungen ergeben, z. B. das Entfernen von Eigenschaften, das Hinzufügen von Verhalten oder Änderungen der Klassenhierarchie? (Dies ist auch etwas wahrscheinlich.)

Unterm Strich scheint es ein Kompromiss zwischen TROCKEN (# 1) und Entkopplung (# 2) zu sein.

Ich neige dazu, mit Nummer 1 zu beginnen und dann, wenn Probleme auftreten, später mit Nummer 2 fortzufahren, und folge dabei der agilen Richtlinie, nicht das zu bauen, was man nicht beweisen kann, dass man es braucht. Ist das eine schlechte Idee? soll ich mit # 2 anfangen, wenn ich denke, dass ich trotzdem dort landen kann?

Fehlen in meinen Listen wichtige Argumente / Konsequenzen?

Gute Frage, einfach gesagt, entkoppeln. Das ist der richtige Weg, Sie möchten nicht an die Java-Version gebunden sein.

Es gibt ein Szenario, das Sie nicht entkoppeln können: Wenn Ihre Technologie das Senden von nicht typspezifischen Objekten über das Netzwerk ermöglicht, können Sie die aktuellen Java-Objekte jetzt als YAGNI verwenden und durch ein anderes ersetzen Typ, den Sie anpassen, ist ein einfaches Drop-In, das aufgrund von Typinformationen, die über das Kabel übertragen werden, nichts kaputt macht. Wenn also die Typinformationen den Draht nicht kreuzen, können Sie YAGNI darauf anwenden.

Seien Sie nur sehr vorsichtig und achten Sie darauf, dass durch Upgrades auf Ihre Java-Version keines dieser Objekte geändert wird. Ansonsten entkoppeln Sie jetzt einfach und sorgen Sie sich nicht darum. Ich denke, es hängt davon ab, wie viel Zeit Sie haben, wenn Sie eine Wahl haben.

Wenn jedoch die Typinformationen in Ihrem Protokoll über die Leitung gehen, ist ein einfaches Einfügen neuer Typen, wenn sich die zugrunde liegenden Java-Typen ändern, möglicherweise nicht möglich und eher ein größerer Aufwand. Wenn dies der Fall ist, bedeutet YAGNI jetzt, technische Schulden und Risiken in Bezug auf Ihre zugrunde liegende Technologie zu akkumulieren.

Persönlich würde ich mich gerade jetzt entkoppeln.

DRY spielt auch keine Rolle, weil Sie die zugrunde liegenden Teile nicht geschrieben haben, damit Sie den Code nicht duplizieren und daher die Schmerzen von Fehlern nicht wiederholt bekommen, was das Hauptanliegen von DRY (und der allgemeinen Wartbarkeit) ist Probleme, die Sie nicht haben werden, weil Sie keine Duplikate zu pflegen haben)

Die Hauptargumente für # 1 sind einfache Implementierung und Upgrades, aber werden Ihre Anforderungen erfüllt?

In Ihren Argumenten für # 2 geben Sie an, dass sich die Java-API und die REST-API wahrscheinlich unabhängig voneinander ändern. Dies bedeutet, dass es sich um separate Anliegen handelt und Sie sich nicht durch die Verwendung separater Klassen wiederholen. Nur weil zwei Dinge gleich aussehen, heißt das nicht, dass sie gleich sind .

Ihre REST-API muss nicht der gleichen Struktur wie Ihr Datenmodell folgen

Stellen Sie bei der Implementierung von REST sicher, dass Sie eine intuitive externe API erstellen, und ordnen Sie diese dann Ihren internen Datenmodellklassen zu. Auf diese Weise können Sie die einzelnen APIs unabhängig voneinander ändern, was zu APIs führt, die Jahrzehnte dauern können .

Entkopplung ist daher der richtige Weg.