guasti SOAP o oggetto risultati?

Question

Avevo una discussione su questo con un collega e non siamo riusciti a raggiungere un accordo, quindi volevo avere i vostri pensieri. Ho le mie opinioni su questo, ma non lo rovinerò per te.

Quando devo ritornerò un errore SOAP e quando dovrei restituire un oggetto risultato che ha informazioni di errore? Supponiamo che questo sia per un servizio web generico che può essere consumato da vari sistemi (.NET, Java, qualunque cosa). L'oggetto risultato avrebbe un flag isError, un errorType (simile al tipo di eccezione specifico) e un messaggio.

alcuni punti da considerare:

1. è un errore di convalida dei dati di un guasto?
2. Dovrebbe esserci una combinazione di guasti (per casi molto eccezionali) e l'oggetto risultati (per errori "attesi")?
3. Come si raggruppano i guasti SOAP (fondamentale [riferimento null] rispetto alla convalida [codice postale errato])?
4. Fail-veloce vs dover ricordare di verificare la presenza di errori
5. migliori pratiche, modelli, norme, ecc

Link ad articoli sono validi. Anche se sembra che io voglia la tua opinione, si prega di attenersi ai fatti (x è migliore a causa di y e z ...)

Answer 1

La maggior parte dei client SOAP convertirà i guasti in un'eccezione di runtime (se questo è qualcosa il client supporti linguistici). Con questo in mente, penso che potresti riformulare la domanda come "Quando voglio lanciare un'eccezione invece di restituire un valore di errore"? Sono sicuro che puoi trovare molte opinioni su quel design dell'API in generale e su quell'argomento in particolare.

Detto questo, restituendo un errore di solito non è utile al cliente:

1. Il cliente ha bisogno di enumerare e gestire i codici di errore contro permettendo il codice stub per generare e un'eccezione del manuale tipo appropriato. L'uso dei codici di errore impedisce al client di utilizzare tecniche orientate agli oggetti come la gestione delle eccezioni per superclasse.

2. Se non si rendono i codici di errore parte del WSDL; il cliente non avrà documentazione su cosa sono o quando si verificano. Gli errori tipizzati fanno parte del WSDL e quindi (in misura limitata) sono autodocumentanti.

3. I messaggi di errore possono contenere il contesto specifico di errore che il client può utilizzare per la segnalazione e il ripristino degli errori. Ad esempio, lanciando un errore di convalida dell'input contenente l'elemento di input non valido effettivo e un motivo. Se si restituisce un risultato con un codice di errore e una stringa opaca, il cliente ha poca scelta ma per passare il tuo messaggio di errore per l'utente, che rompe l'internazionalizzazione, la coerenza dell'interfaccia utente, ecc

Per rispondere alla sua specifica domande:

1. Un errore di convalida è un errore. Immagina se invochi il servizio web da un client AJAX con capacità di gestione degli errori limitata; si desidera che il servizio restituisca un codice HTTP 5xx, non un 400 codice di successo con una risposta inaspettata.

2. No. Le API devono fornire interfacce di segnalazione degli errori coerenti. Il design WSDL è design API. Costringere il client a implementare due distinti gestori di errori non semplifica la vita del cliente.

3. Il disegno di errore deve rispecchiare il modello di richiesta/risposta e visualizzare le informazioni appropriate all'astrazione del servizio. Non progettare un errore NullReference; progettare un XYZServiceRuntimeFault. Se i client forniscono spesso richieste non valide, progettare un InvalidRequestFault, con sottoclassi appropriate in modo che i client possano capire rapidamente dove si trovano i dati non validi.

Answer 2

Un oggetto risultati deve contenere solo risultati. Se il tuo oggetto risultato sta fornendo un elenco di errori che si sono verificati su un altro sistema, allora questo è un esempio di quando puoi avere e il flag "isError"; altrimenti non puoi perché un risultato è valido o no.

Si dovrebbe sempre utilizzare SOAPFault quando si verifica un errore. La validazione è un errore, ed è proprio la trappola dei diavoli a pensare che la convalida sia meno grave di un'incapacità di aprire un database. Entrambi i casi hanno lo stesso impatto: l'operazione non può essere completata come richiesto.

Quindi è necessario utilizzare oggetti risultato per risultati e errori SOAP per tutto ciò che impedisce un oggetto risultato valido; inclusi, ma non limitati a errori, errori di validazione, avvisi, errori bus, ecc.

Nei giorni precedenti alle eccezioni non c'era scelta e di conseguenza molte API divennero incoerenti e la maggior parte delle API differiva su come restituire un errore. Era (ed è tuttora) orribile, confuso e spesso rallenta lo sviluppo perché devi cercare in che modo ogni voce API restituisce un errore, e spesso come decodificare o scoprire di più sull'errore.

1. Per gestire la convalida con SOAPFaults/eccezioni è più logico se si pensa a questo proposito, e una volta che hai pensato di solito è più facile. È necessario progettare la classe di errore di convalida in modo che contenga informazioni sufficienti per identificare gli elementi offensivi in ​​un modo che non richiede necessariamente la richiesta originale. In questo modo puoi iniziare a gestire gli errori di convalida in modo più generico.

2. Se l'oggetto risultati contiene errori, possono essere solo all'interno del dominio dei risultati; ad esempio Prodotto esaurito perché qualcuno nel wharehouse non può contare è nel dominio del controllo di inventario.

3. Non è opportuno fare la distinzione tra un errore critico e un errore di convalida, questo a mio avviso non è un confronto valido perché qualsiasi assegnazione del livello di gravità è molto soggettiva. Ad esempio, in un sistema che fornisce informazioni sulle sostanze chimiche a un vigile del fuoco, è fondamentale che il camion sia in possesso dell'ONU 1298 & UN 1436 e non un riferimento nullo quando si tenta di caricare il grafico di avvertenza.

   Progettare i guasti in modo da consentirne l'identificazione concisa e gestita di conseguenza. Garantire che trasmettano informazioni sufficienti. La categorizzazione abritraria è qualcosa di inutile quando hai informazioni sufficienti perché il Guasto si lascerà identificare.

4. SOAPFaults trasformati in Eccezioni sono il modo più sicuro di avere una soluzione rapida.

5. Buone pratiche, riferimenti ecc.

   • Managing Exceptions in a SOA world: Ramesh Ranganathan

   • When Exceptions Are the Rule : Achieving reliable and traceable service-oriented architectures

   • Best practices on SOAP Faults

   • Use SOAP Faults to deliver the appropriate level of detail to the developer at development time, and to the customer while the Web service is in production.

   • Web services use SOAP faults to report fault cases back to clients. The faults can be generated from the SOAP framework in a case of invalid SOAP messages, invalid security tokens or they can be generated from the service business logic itself

   • SOAP fault messages are the mechanism by which SOAP applications report errors “upstream,” to nodes earlier in the message path. It's the mission of this section to provide a full and detailed explanation of SOAP faults so that you can handle them appropriately in your own Web services.

Answer 3

Penso che la risposta breve è usare un errore SOAP, se non si conosce il cliente sarà in grado di gestire un errore restituito come risultato. Stavo anche pensando all'analogia tra le eccezioni e i risultati degli errori, come menzionato nelle altre risposte.

Ci sono aree grigie che possono essere ragionevolmente trattate come eccezioni e come risultato errori a seconda delle esigenze del cliente. È quindi possibile fornire un parametro al servizio che altera il modo in cui vengono restituiti questi tipi di errore. L'impostazione predefinita prevede l'utilizzo di un errore SOAP, ma se il client imposta il parametro per ottenere i risultati dell'errore, indica che è disposto a gestirlo come parte del risultato. Per me, gli errori di validazione sono in questa area grigia. Per la maggior parte dei client dovrebbero essere considerati errori, ma se il cliente desidera utilizzare i dati per contrassegnare l'interfaccia utente con errori di convalida, restituire gli errori di convalida come parte del risultato potrebbe essere più utile.  

Answer 4

La regola seguo nel design il servizio è:

• livello di business risposta (anche eccezioni di business) in risposta oggetti
• livello/integrazione tecnica difetti in sapone Fault

Il consumatore del servizio può fare affidamento sul fatto che ogni tipo di risposta aziendale arriva in oggetti risposta e la presenta al servizio (busi utenti). Gli errori di sapone vengono utilizzati solo quando non è possibile fornire una risposta aziendale.

I Soap Faults devono attivare un avviso/azione di supporto tramite monitoraggio.