Sollte ein REST-service über eine XSD für XML-Antworten?

Wir haben ein REST-service, der je nach accept-header zurück, XML oder JSON an den client, oder je nach content-type-header akzeptieren, XML oder JSON.

Nun eine aktuelle integrator fragte uns, ob wir ein XSD-schema für die XML-Antworten und Anfragen.

Ist dies eine gängige Praxis bei der Entwicklung von REST-services?

InformationsquelleAutor Luc Bos | 2014-11-24
  1. 6

    Ist es absolut gängige Praxis, Aufrufer des service, einschließlich der REST, mit irgendeiner form der definition der Schnittstelle für diesen Dienst. Wenn Sie über eine XML-Schnittstelle, XML-schema-von einer Art (XSD, RELAX NG, Schematron, etc) ist eine feine Art zu definieren, die Anfrage und Antwort - Schnittstelle. Neben der Bereitstellung der Dokumentation, es kann verwendet werden, durch die überprüfung der Parser zu fangen, Verstöße gegen die deklarierten interface.

    Könnten Sie auch erwägen, JSON-Schema Definitionen Ihrer JSON-Schnittstelle. Es bietet einige der gleichen Vorteile wie ein XML-schema würde, aber es ist wohl weniger "gängige Praxis" als XML-schemas für XML.

    • Ist JSON-Schema-Spezifikation fertig gestellt? Wird es intensiv genutzt? Eine andere Sache, die ich gestoßen bin, für den REST war RAML (raml.org).
    • Gute Fragen. Ich bin derzeit warnen Kunden, dass die neuesten IETF JSON-Schema-Spezifikation v4, abgelaufen im August 2013, und dass diejenigen, die Verwendung von JSON selten verwenden JSON-Schema.
    InformationsquelleAutor kjhughes
  2. 5

    Den vorherigen Antworten richtig sind, dass dies gemeinsamen Praxis.

    Allerdings empfehle ich, die ist nicht gute Praxis.

    Die schlechte Sache über die Verwendung eines xsd zum validieren einer Reaktion, ist die enge Bindung, die Sie zwischen dem client und dem server. Im Idealfall würde ein Kunde Folgen der tolerante Leser-Muster (siehe, zB, http://martinfowler.com/bliki/TolerantReader.html). Sollte der client benötigt nur die Daten, die es braucht, und nicht scheitern unnötig. Also, wenn der server zu starten, sendet zusätzliche Daten, oder nicht, senden Sie nicht mehr benötigte Daten, die der client sollte in der Lage sein, um fortzufahren, ohne zu Klagen. Die client-domain-Modell repräsentieren sollten nur die Daten, die der Kunde tatsächlich benötigt.

    Zurück in den alten Tagen der SEIFE, diese enge Bindung zwischen client und server akzeptiert wurde als ok, oder sogar gut, und durchgesetzt werden die wsdl-und xsd. REST-Architekturen fördern sollte lose Kopplung statt, und es Diensten ermöglicht, sich zu entwickeln mit so wenig Auswirkungen wie möglich.

    Mit der xsd-Datei zur Validierung eine Antwort ist gut, nur in seltenen Fällen. Zum Beispiel, wenn der service wird sich auch nie ändern (es könnte ein Wegwerf-Dienst zu tun, wenn-aus-Daten-migration), oder wenn Sie denken, es ist ok, um die client-und server-Domäne-Modelle fest gebunden ist (ich denke, das ist ok für unit-tests). Ein argument könnte gemacht werden, die für die Veröffentlichung der xsd-wenn ein Dienst ist stabil, aber ich denke, dass dies eine sehr schwere Entscheidung.

    (und das obwohl diese immer noch gängige Praxis, ich finde, dass es nicht so verbreitet wie es war. Ich war im Gespräch mit einer Architektin bei einer großen Regierungsbehörde Letzte Woche, und Ihr standard ist nur xpath verwenden, um Daten aus xml-Antworten, und verwenden Sie niemals domain-Objekten auf Basis einer xsd)

    • -1 für den Angriff auf eine Strohmann. Sie sagen: "es ist keine gute Praxis," aber die es, ich verwiesen war "irgendeine form von definition der Schnittstelle für das service", nicht "mit einem xsd zu generieren, domain-Objekte," oder "mit der xsd-Datei zu generieren, die Kunden gut [sic]."
    • Danke für den Punkt - es ist ein guter. Ich habe entfernt, jeglicher Bezug zum generieren von domain-Objekten, da es nicht erwähnt in Ihrer Antwort. Ich umfasste domain-Objekte als weiteres Beispiel für die enge Kopplung zwischen client und server, die wir sehen, ziemlich oft. Ich dachte, es war interessant und relevant in dem Zusammenhang, aber es war eine Abschweifung. Ich habe auch die getönten meine Antwort ein wenig runter, da kann ich jetzt sehen, wie es geben könnte straftat.
    • Die Schwäche Ihrer Argumentation weiterhin über Ihre kleinere änderungen. Sie verschmelzen enge Kopplung (schlecht) mit Vertrag-definition und Einhaltung der (gute Dinge), und irgendwie das Gefühl gerechtfertigt zu verkünden, dass der Vertrag definition und Einhaltung sind daher schlechte Dinge. 100% falsch. Lose Kopplung bedeutet nicht, dass die Vermeidung von Schnittstellen-definition; es bedeutet die Vermeidung von Abhängigkeiten zwischen Implementierungen. ich hoffe, ich habe geholfen, Voraus Ihr Verständnis in diesem Bereich, aber, egal, ich werde Ausrücken an dieser Stelle. Viel Glück.
    • Vertrag definition und Einhaltung sind guter Dinge. Robust Kunden, die vielleicht in der Lage sein, um fortzufahren, selbst wenn die änderungen im Vertrag (oder bei einem Ausfall des Verlegers zu halten), sind nicht im Widerspruch, und sind auch guter Dinge. Was darauf hindeutet, dass ein client validiert die Antwort, die er erhält durch ein xsd-ist das Gegenteil von dieser permissiven Ansatz. Es macht aber sehr viel Sinn, um zu validieren vor dem senden ein request-oder response - dies ist auch sinnvoll, und nicht mit der tolerant reader Muster. Vielen Dank für Ihren Kommentar und alles gute auch für Sie.
    InformationsquelleAutor Brian
  3. 2

    Warum nicht? Wenn Sie die Kommunikation via XML, dann können Sie schemaLocation Attribut geben Sie Ihre URL-schema. Ansonsten, wie client können überprüfen der server-XML und bildet seine eigenen Anforderungen richtig?

    InformationsquelleAutor nikita
Schreibe einen Kommentar