REST API - DTOs oder nicht?

Ich bin derzeit auf der Erstellung einer REST-API für ein Projekt und lese Artikel, die auf Artikel über "best practices". Viele scheinen gegen DTOs und einfach nur aussetzen, domain-Modell, während andere scheinen zu denken, DTOs (oder Benutzer Modelle oder was auch immer Sie es nennen wollen) sind eine schlechte Praxis. Persönlich, ich dachte, dass dieser Artikel eine Menge Sinn.

Allerdings verstehe ich auch die Nachteile von DTOs mit all den zusätzlichen mapping-code, domain-Modelle, die möglicherweise 100% identisch zu der DTO-Pendant und so weiter.

Unsere API ist meist so angelegt, dass andere clients beanspruchen kann, ist-Daten, aber wenn wir es richtig machen, würden wir auch gerne für unsere eigene web-GUI, wenn möglich.

Die Sache ist die, dass wir möglicherweise nicht verfügbar machen möchten, alle domain-Daten an den anderen client-Benutzer. Der Großteil der Daten wird nur dann Sinn machen, in unserem eigenen web-Anwendung. Auch wir möglicherweise nicht verfügbar machen möchten, werden alle Daten über ein Objekt in allen Szenarien, insbesondere die Beziehungen zu anderen Objekten und so weiter. Zum Beispiel, wenn wir über eine Liste von einem bestimmten Objekt würden wir nicht unbedingt wollen, setzen Sie das gesamte Objekt-Hierarchie, so dass das Objekt, das die Kinder nicht ausgesetzt werden, sondern kann entdeckt werden durch links (hateoas).

Wie soll ich über die Lösung dieses Problems? Ich dachte über die Verwendung von Jackson Mixins in Verbindung auf unsere domain-Modelle zu Steuern, welche Daten zur Verfügung gestellt würden verschiedene Szenarien. Oder sollten wir einfach die Verwendung von DTOs alle Weg - auch angesichts Ihrer Nachteile und kontroversen?

InformationsquelleAutor der Frage benbjo | 2016-03-23

  1. 130

    Warum sollten Sie die Verwendung von DTOs in Ihrer REST-API

    DTO steht für Data Transfer Objekt.

    Dieses Muster wurde mit einem sehr gut definierten Zweck: übertragen von Daten auf remote-interfaceswie web services. Dieses Muster passt sehr gut in eine REST-API und DTOs wird Ihnen mehr Flexibilität im langen Lauf.

    REST-Ressourcen Darstellungen nicht brauchen, um haben die gleichen Eigenschaften wie die Persistenz-Modelle: Sie müssen möglicherweise das weglassen, hinzufügen oder umbenennen von Attributen.

    Nur einige zu nennen, nutzen offenlegen DTOs statt Persistenz-Modelle:

    • DTOs werden kann zugeschnitten auf Ihre Bedürfnisse und Sie sind groß, wenn Sie nur die Attribute von der Persistenz-Einheiten. Sie nicht brauchen, Anmerkungen, wie @XmlTransient und @JsonIgnore zu vermeiden, ist die Serialisierung von einigen Parametern.
    • Durch die Verwendung von DTOs vermeiden Sie, dass Sie eine Hölle Anmerkungen in der Persistenz-Einheiten, das heißt, Ihr persistence entities werden nicht aufgebläht mit nicht-Persistenz-bezogene Anmerkungen;
    • Sie haben die volle Kontrolle über die Attribute erhalten Sie beim erstellen oder aktualisieren einer Ressource;
    • Wenn Sie Swaggerdie Sie verwenden können, @ApiModel und @ApiModelProperty Anmerkungen dokumentieren Sie Ihre API-Modelle ohne messing mit der Persistenz von Entitäten;
    • Können Sie verschiedene DTOs für jede version Ihrer API;
    • Haben Sie mehr Flexibilität beim zuordnen von Beziehungen;
    • Können Sie verschiedene DTOs für die verschiedenen Medien-Typen;
    • Ihre DTOs haben eine Liste von links für HATEOAS. Das ist die Art von Sache, die Sie sollten nicht Hinzugefügt werden, um die Persistenz von Objekten.

    Mapping-frameworks

    Werden Sie nicht brauchen, um die Karte mit der Persistenz von Entitäten zu DTOs und Umgekehrt mannually. Es gibt viele mapping-frameworksdie Sie verwenden können, um es zu tun. Zum Beispiel haben Sie einen Blick auf MapStructdie auf Basis einer annotation und arbeitet als Maven-Annotation-Prozessor. Es funktioniert auch in CDI und Spring-basierten Anwendungen.

    Verwandte: Zu geben, bessere Namen zu Ihrem DTO-Klassen finden Sie auf dieser Antwort.

    InformationsquelleAutor der Antwort Cassio Mazzochi Molin

  2. 11

    Wenn Ihre API ist öffentlich und Sie haben die Unterstützung mehrerer Versionen, dass man mit DTOs.

    Auf der anderen Seite, wenn es private API und Sie Steuern sowohl der client als auch server, ich neigen zu überspringen, der DTOs und setzen direkt domain Modell.

    InformationsquelleAutor der Antwort David Siro

  3. 9

    Neige ich zum DTOs.

    Ich weiß nicht, wie die Nachteile, aber es scheint, dass die anderen Optionen sind noch schlimmer:

    Ausstellung der domain-Objekte kann zu Sicherheitsproblemen führen und Daten-Leck.
    Jackson Anmerkungen scheinen kann, um das problem zu lösen, aber es ist zu einfach, Fehler zu machen und setzen Sie Daten, die nicht ausgesetzt werden.
    Bei der Gestaltung einer DTO-Klasse, es ist viel schwieriger, einen solchen Fehler.

    Auf der anderen Seite die Nachteile des DTO-Ansatz reduziert werden können mit Sachen wie-Objekt zu Objekt-mapping und Lombok für weniger boilerplate.

    InformationsquelleAutor der Antwort Argb32

  4. 4

    Wie du schon gesagt hast sich selbst, das ist ganz klar eine Stellungnahme Frage. Ich selbst bin mehr gezogen, um die Nicht-DTOs Ansatz, einfach wegen all der boilerplate-code, den Sie brauchen.

    Dies ist vor allem für die response-Seite von json/rest-api. Ich schrieb sogar eine jackson addon zu vermeiden, schreiben viele json-Ansichten /Filter für diese Fälle: https://github.com/Antibrumm/jackson-antpathfilter

    Auf der anderen Seite DTOs sind eine gute Sache auf die Anfrage input-Seite der APIs. Direkt auf Entitäten können ziemlich schwer werden unter Berücksichtigung der bidirektionalen Beziehungen zum Beispiel. Auch Sie nicht wirklich wollen, lassen Sie einen Anrufer ändern "Schöpfer" - Attribut, zum Beispiel. So würden Sie brauchen, um dissallow bestimmte Felder während der Zuordnung solcher Anfragen.

    InformationsquelleAutor der Antwort Martin Frey

Schreibe einen Kommentar