Błędy mydła czy rezultaty?

Obiekt results powinien zawierać tylko wyniki. Jeśli obiekt result dostarcza listę błędów, które wystąpiły w innym systemie, to jest to przykład, kiedy możesz mieć i flagę "isError"; w przeciwnym razie nie możesz, ponieważ wynik jest ważny lub nie.

Zawsze powinieneś używać SOAPFault, gdy wystąpi błąd. Walidacja jest błędem i pułapką diabłów jest myślenie o walidacji jako o mniej poważnej niż niemożność otwarcia bazy danych. Oba przypadki mają ten sam wpływ-operacja nie może zostać zakończona zgodnie z żądaniem.

Więc powinieneś używać obiektów wynikowych dla wyników i błędów SOAP dla wszystkiego, co uniemożliwia poprawny obiekt wynikowy; w tym, ale nie ograniczając się do błędów, błędów walidacji, ostrzeżeń, błędów magistrali itp..

W dniach poprzedzających wyjątki nie było wyboru i w rezultacie wiele interfejsów API stało się niespójnych, a większość interfejsów API różniła się sposobem zwracania błędu. Było (i nadal jest) straszne, mylące i często spowalnia rozwój, ponieważ musisz sprawdzić, jak każdy wpis API zwraca błąd, a często jak dekodować lub dowiedzieć się więcej o błędzie.

1. Obsługa walidacji za pomocą Soapfaults / Exceptions jest bardziej logiczna, gdy o tym pomyślisz, a gdy już o tym pomyślisz, zwykle jest łatwiejsza. Należy zaprojektować klasę błędów walidacji w taki sposób, aby zawierała ona wystarczające informacje, aby zidentyfikować elementy naruszające prawo w sposób niekoniecznie wymagający pierwotnego żądania. This way you może zacząć obsługiwać błędy walidacji bardziej ogólnie.

2. Jeśli obiekt results zawiera błędy, mogą one znajdować się tylko w domenie wyników; na przykład Product out of stock ponieważ ktoś w wharehouse nie może liczyć jest w domenie kontroli zapasów.

3. Nie jest mądre rozróżnianie między błędem krytycznym a błędem walidacji, to moim zdaniem nie jest poprawne porównanie, ponieważ każde przypisanie poziomu ważności jest bardzo subiektywne. Na przykład w systemie dostarczającym informacje o chemikaliach strażakowi, krytyczne prawdopodobnie oznacza, że ciężarówka w ogniu niesie UN 1298 i UN 1436, a nie zerowe odniesienie podczas próby załadowania Grafiki ostrzegawczej.

   Zaprojektuj usterki, aby umożliwić ich zwięzłą identyfikację i odpowiednie postępowanie. Zapewnić, aby przekazywały one wystarczające informacje. Kategoryzacja abrytrary jest czymś, co jest niezauważalne, gdy masz wystarczającą ilość informacji, ponieważ Wina pozwoli się zidentyfikować.

4. SOAPFaults zamienione w wyjątki są najpewniejszym sposobem na szybkie niepowodzenie.

5. Najlepsze praktyki, referencje itp.

   • Zarządzanie wyjątkami w świecie SOA: Ramesh Ranganathan

   • Gdy regułą są wyjątki : osiągnięcie niezawodnych i identyfikowalnych architektur zorientowanych na usługi

   • Najlepsze praktyki w zakresie mydła Wady

   • Wykorzystaj błędy SOAP, aby dostarczyć odpowiedni poziom szczegółowości deweloperowi w czasie opracowywania i klientowi, gdy usługa internetowa jest w produkcji.

   • Serwisy internetowe wykorzystują błędy SOAP do zgłaszania przypadków usterek klientom. Błędy mogą być generowane z frameworka SOAP w przypadku nieprawidłowych wiadomości SOAP, nieprawidłowych tokenów bezpieczeństwa lub mogą być generowane z logiki biznesowej usługi itself

   • Jeśli wyślesz wiadomość, która z jakiegoś powodu nie powiodła się, możesz otrzymać odpowiedź zawierającą element błędu SOAP, który zawiera informacje o stanie, błędach lub obu. W wiadomości może być tylko jeden element błędu Mydła i musi to być wpis w ciele mydła. Ponadto, jeśli w ciele mydła znajduje się element błędu mydła, nie może być innych elementów w ciele mydła. Oznacza to, że po dodaniu elementu błędu mydła, masz skutecznie zakończono budowę korpusu mydła.

   • Komunikaty błędów SOAP są mechanizmem, za pomocą którego aplikacje SOAP zgłaszają błędy "upstream" do węzłów wcześniej w ścieżce wiadomości. Misją tej sekcji jest dostarczenie pełnego i szczegółowego wyjaśnienia usterek SOAP, tak aby można było je odpowiednio obsłużyć we własnych serwisach internetowych.

Myślę, że krótka odpowiedź to użyj błędu mydła, chyba że wiesz, że klient będzie przygotowany do obsługi błędu zwróconego w wyniku. Myślałem również o analogii między wyjątkami a błędami, jak wspomniano w innych odpowiedziach.

Istnieją szare obszary, które mogą być zarówno racjonalnie traktowane jako wyjątki, jak i jako błędy w wyniku w zależności od potrzeb klienta. Następnie możesz podać parametr do usługi, który zmienia sposób zwracania tego typu błędów. Na domyślne jest użycie błędu SOAP, ale jeśli klient ustawia parametr, aby uzyskać wynik błędu, to oznacza, że jest gotów obsłużyć to jako część wyniku. Dla mnie błędy walidacji są w tej szarej strefie. W przypadku większości klientów powinny one być uważane za błędy, ale jeśli klient chce użyć danych do oznaczania interfejsu użytkownika błędami walidacji, zwrócenie błędów walidacji jako części wyniku może być bardziej użyteczne. 

Zasada, którą kieruję się w projektowaniu usług to:

• poziom biznesowy odpowiedź (nawet wyjątki biznesowe) do obiektów odpowiedzi
• poziom techniczny/integracyjny błędy w usterce Soap

Konsument usługi może polegać na tym, że wszelkiego rodzaju odpowiedzi biznesowe pojawiają się w obiektach odpowiedzi i prezentują je użytkownikom usług (biznesowych). Błędy Soap są używane tylko wtedy, gdy odpowiedź biznesowa nie może być dostarczona.

Błędy Soap powinny wywołać wsparcie Ostrzeżenie / działanie poprzez monitorowanie.