SOAP-Fehler oder Ergebnisobjekt?

Ich hatte eine Diskussion darüber mit einer Kollegin und wir konnte nicht zu einer Einigung kommen, so wollte ich Ihre Gedanken. Ich habe meine eigenen Meinungen dazu, aber ich werde nicht verderben es für Sie.

Wann sollte ich wieder ein SOAP-fault und Wann soll ich wieder ein Ergebnis-ObjektFehler Informationen? Nehme an, dies ist für eine generische web-service konsumiert werden kann, die von verschiedenen Systemen (.NET, Java, was auch immer). Das Ergebnis-Objekt hätte eine isError-Flagge, eine errorType (ähnlich spezifische exception-Typ), und eine Nachricht.

Einige Punkte zu beachten:

  1. Ist ein Daten-Fehler bei der überprüfung ein Fehler?
  2. Sollte es eine Kombination von Fehlern (für sehr außergewöhnliche Fälle) und die Ergebnisse Objekt ("erwartete" Fehler)?
  3. Wie würden Sie die Gruppe SOAP-Fehler (critical [null] vs Validierung [zip code falsch])?
  4. Fail-fast-vs zu müssen, denken Sie daran zu prüfen, Fehler
  5. Best practices, patterns, standards, etc.

Links zu Artikeln gültig sind. Auch wenn es klingt wie ich will Ihre Meinung, halten Sie sich bitte an Fakten (x ist besser, weil y und z...)

InformationsquelleAutor der Frage Nelson Rothermel | 2010-05-12

  1. 57

    Meisten SOAP-clients konvertieren die Fehler in eine exception zur Laufzeit (wenn das ist etwas, was die client-Sprache unterstützt). Mit dem im Verstand, denke ich, könnte man formulieren Sie die Frage "Wann will ich eine exception werfen, statt einen Fehler-Wert"? Ich bin sicher, Sie finden viele Meinungen über diese API-design im Allgemeinen und dieses Thema im besonderen.

    Sagte, einen Fehler, ist in der Regel nicht hilfreich für den AUFTRAGGEBER:

    1. Muss der client manuell auflisten und Bearbeiten Sie Ihre Fehler-codes vs. ermöglicht, die dem stub-code zu generieren und eine Ausnahme auslösen des entsprechenden Typs. Mit Fehler-codes verhindert, dass den client mit Objekt-orientierten Techniken wie die Handhabung von Ausnahmen die von Superklasse.

    2. Wenn Sie nicht machen Ihre Fehler-codes, die Teil der WSDL; der client wird keine Dokumentation haben, auf das, was Sie sind oder, wenn Sie auftreten. Getippt, Fehler sind Teil des WSDL-und daher (bis zu einem gewissen begrenzten Umfang) selbst dokumentieren.

    3. Fehlermeldungen können enthalten Schuld-spezifische Kontext, in dem der client machen für die Fehler-reporting und-Wiederherstellung. Zum Beispiel, werfen eine input-Validierung Fehler enthält, die tatsächliche ungültige Eingabe-element und einen Grund. Wenn man wieder ein Ergebnis mit einem Fehler-code und ein undurchsichtig string, der Kunde hat wenig Wahl, aber, um Ihren pass Fehlermeldung an den Benutzer, die Pausen Internationalisierung mit UI-Konsistenz, etc.

    Zur Beantwortung Ihrer konkreten Fragen:

    1. Einem Fehler bei der überprüfung ist ein Fehler. Stell dir vor, Sie rufen die web-service von einem AJAX-client mit limited error-handling-Fähigkeit; Sie wollen den service für die Rückkehr einen 5xx-HTTP-code, nicht ein 400 Erfolgs-code, mit einigen unerwarteten Reaktion.

    2. Nicht. APIs sollte eine konsequente Fehler-reporting-Schnittstellen. WSDL-design-API-design. Zwingt den client zu implementieren zwei unterschiedliche Fehler-Handler nicht machen den Kunden das Leben leichter.

    3. Schuld design sollte Spiegel Ihre Anforderung/Antwort-Modell und Anzeige von Informationen geeignet, um die Abstraktion des service. Nicht design eine NullReference-Fehler; Entwurf einer XYZServiceRuntimeFault. Wenn clients Häufig ungültigen Anfragen, die Gestaltung eines InvalidRequestFault, mit entsprechenden Unterklassen, so dass die Kunden können schnell herausfinden, wo der ungültige Daten.

    InformationsquelleAutor der Antwort gibbss

  2. 43

    Einen Ergebnis-Objekt sollte nur die Ergebnisse. Wenn das Ergebnis-Objekt stellt eine Liste der Fehler, die aufgetreten sind auf einem anderen system, dann ist das ein Beispiel, wenn Sie haben können und "ISTFEHLER" - flag, sonst können Sie nicht, weil ein Ergebnis ist entweder gültig oder nicht.

    Sollten Sie immer mit ein SOAPFault, wenn ein Fehler Auftritt. Die Validierung ist ein Fehler, und es ist der Teufel eigene Falle zu denken, der Validierung als weniger schwerwiegend als eine Unfähigkeit, eine Datenbank zu öffnen. Beiden Fällen die gleiche Wirkung haben - der Vorgang kann nicht abgeschlossen werden, wie gewünscht.

    So sollten Sie durch Objekte, die für Ergebnisse und SOAP-Fehler für alles, was verhindert, dass eine gültige Ergebnis-Objekt; einschließlich, aber nicht beschränkt auf Fehler, überprüfung Fehler -, warn -, bus-Fehler, etc..

    In den Tagen vor Ausnahmen gab es keine Wahl, und als Folge viele APIs wurde inkonsistent und die meisten APIs unterschieden sich, wie um einen Fehler zurückzugeben. Es war (und ist) schrecklich, verwirrend und oft verlangsamt die Entwicklung, da müssen Sie nachschlagen, wie die einzelnen API-Eintrag gibt einen Fehler zurück, und oft, wie Sie zu entschlüsseln oder erfahren Sie mehr über den Fehler.

    1. Verarbeiten-Validierung mit SOAPFaults /Ausnahmen mehr logisch, wenn man darüber nachdenkt, und wenn Sie nachgedacht habe, ist es meist einfacher. Sie müssen das design, die Validierungs-Fehler-Klasse, so dass es enthält genug Informationen, um zu identifizieren, die problematischen Elemente in einer Weise, die nicht unbedingt erfordern die ursprüngliche Anforderung. Auf diese Weise können Sie beginnen, zu behandeln Validierungsfehler mehr generisch.

    2. Wenn die Ergebnisse Objekt enthält Fehler, die Sie nur innerhalb der Domäne der Ergebnisse, zum Beispiel Produkt vergriffenweil jemand in der wharehouse kann nicht zählen, ist im Bereich der Lagerverwaltung.

    3. Es ist nicht klug, zu unterscheiden, ob ein Kritischer Fehler und ein Fehler bei der überprüfung dieser meiner Meinung nach ist kein zulässiger Vergleich, weil keine Abtretung der Schweregrad ist sehr subjektiv. Zum Beispiel in einem system, die Bereitstellung von Informationen über Chemikalien haben, ein Feuerwehrmann, kritisch bedeutet wahrscheinlich, dass der LKW auf Feuer Sie ist Schwanger UN-1298 & UN 1436 und nicht eine null-Referenz beim laden die Warnung Grafik.

      Design, die Fehler in Ihnen zu ermöglichen, identifiziert werden, die kurz und prägnant und entsprechend behandelt. Sicherzustellen, dass Sie vermitteln genügend Informationen. Abritrary Kategorisierung ist etwas, das ist unncessary wenn Sie schon über ausreichende Informationen, weil der Fehler lässt sich identifizierten.

    4. SOAPFaults sich in Ausnahmen sind der sicherste Weg, dass die fail-schnell.

    5. Best practices, Referenzen usw..

    InformationsquelleAutor der Antwort Richard Harrison

  3. 7

    Ich glaube, die kurze Antwort ist, verwenden Sie eine soap-fault, es sei denn, Sie wissen, die client ausgestattet werden, um einen Fehler zu behandeln als Ergebnis zurückgegeben. Ich dachte auch die Analogie zwischen Ausnahmen und Fehler die Ergebnisse, wie bereits in den anderen Antworten.

    Gibt es graue Bereiche, die könnten beide werden vernünftig behandelt, als Ausnahmen und als Ergebnis von Fehlern je nach den Bedürfnissen des Kunden. Dann könnten Sie einen parameter angeben, der service, die verändert, wie diese Art von Fehler wird zurückgegeben. Der Standard ist die Verwendung eines SOAP-fault, aber wenn der client setzt die parameter, um Fehler führt, dann ist es darauf hinweist, dass er bereit ist, das zu handhaben, als Teil des Ergebnisses. Für mich, die Validierung, die Fehler sind in dieser Grauzone. Für die meisten Kunden Sie sollten als Fehler, aber wenn der Kunde will die Daten verwenden, um markup-UI mit der Validierung Fehler, dann wieder der Fehler bei der Validierung als Teil des Ergebnisses kann nützlicher sein. 

    InformationsquelleAutor der Antwort mdma

  4. 1

    Den ich in der Regel Folgen Sie in der service design:

    • business-Ebene Antwort (auch business Ausnahmen) in response Objekte
    • technische/integration level Fehler in Soap-Fault

    Den service Verbraucher können sich darauf verlassen, dass alle Arten von Geschäfts-Reaktion ist eine Reaktion Objekte und stellt it service (business) user. Die Soap-Fehler werden nur verwendet, wenn das Geschäft Antwort nicht zugestellt werden kann.

    Den Soap-Fehler auslösen sollte, eine Unterstützung Abmahnung/Klage über die überwachung.

    InformationsquelleAutor der Antwort KarelHusa

Schreibe einen Kommentar