Come gestire l'API risponde con DTO o messaggio di errore

Question

Come gestire l'API risponde con DTO o messaggio di errore

#1 da (1 voti)

0

Ho un'app mobile e un'API. L'app per dispositivi mobili è configurata per l'attesa di un DTO dall'API, ma non ha informazioni se la richiesta non è andata a buon fine. Questo deve essere aggiornato in modo che all'utente venga visualizzato un messaggio migliore. Devo aggiornare l'API e l'app per dispositivi mobili in modo da poter inviare a DTO su una richiesta riuscita o un messaggio che contiene più dettagli di un messaggio di errore generico.

Ho iniziato a modificare i tipi di ritorno API in IHttpActionResult in modo da poter passare i dati AND del codice di stato HTTP.

Il mio primo pensiero è creare un wrapper di richiesta che abbia un messaggio di errore e un oggetto dati generico.

public class ResponseWrapper
{
    public bool IsSuccess{get; set;}
    public string ErrorMsg {get; set;}
    public Object Data {get; set;}
}

Posso quindi controllare il flag IsSuccess e procedere di conseguenza.

Ho anche pensato di impiantare codici di errore o di utilizzare codici di stato HTTP personalizzati. Ma sento che questo aggiunge complessità con il mantenimento dei codici e messaggi associati. Con questa complessità aggiunta precauzionata, questa non sembra la soluzione migliore.

Esiste una soluzione migliore o una pratica standard per l'acquisizione di un DTO o un messaggio di errore nella stessa risposta API?

api .net mobile http-response

posta DFord 14.08.2018 - 16:05

fonte

1 risposta

Leggi altre domande sui tag api .net mobile http-response

come gestire la raccolta di diversi tipi di risorse Caso esemplificativo di quando si utilizza ASP.Net w / Angolare vs solo HTML e Angolare consentirebbe di fornire funzionalità l'altra non

score 1 · Accepted Answer

Da quanto ho capito, stai utilizzando un'API HTTP per la comunicazione tra il client e il server.

Posso solo consigliarti dalle mie preferenze personali, dalle mie convenzioni. Sono abituato a sfruttare il vocabolario HTTP.

Per le API del server UI utilizzo solo i codici di stato. Io mantengo le cose semplici. Per tutte le richieste riuscite, invio il codice di stato 200. Le richieste che cambiano stato sul server non restituiscono nulla al client. In alcuni casi i dati sono richiesti e io mi piego da questa convenzione e continuo a inviare, ma molto raramente. Per le richieste che non cambiano stato come GET, ho appena restituito un json con il codice di stato 200. Ora per eventuali richieste che non riescono (a causa dell'utente o qualcos'altro) non aggiungo alcun dato ad esso, il codice di stato è abbastanza. Codice di stato 400 = azione generica non valida dall'utente (input non valido). Codice di stato 404 per richieste GET quando i dati non vengono trovati. Codice di stato 500 per errore generico del server. Codice di stato 401 quando viene effettuata una richiesta che richiede l'autenticazione.

Come puoi vedere, non ci sono molti codici da tenere sotto controllo. Hai solo bisogno di seguire alcune semplici convenzioni. Le mie convenzioni di base: cercare di non restituire alcun dato quando le richieste cambiano stato (POST). Utilizzare solo quei 5 codici di stato.

Ora, con le mie API sviluppatore, quelle che devono essere consumate programmaticamente da terze parti (non l'interfaccia utente del client), a volte tendo anche ad aggiungere un messaggio personalizzato vicino al codice di stato HTTP e lì a volte userò altri codici di stato rendere la vita degli sviluppatori più facile, perché tendono ad aver bisogno di più informazioni da una risposta HTTP.

Ora perché per l'interfaccia utente le cose possono essere mantenute semplici? Perché è possibile eseguire la maggior parte della convalida nell'interfaccia utente / lato client. Non è necessario restituire le informazioni sugli errori al client, convalidare una richiesta prima che venga inviata. Il client UI in genere deve solo sapere se ha avuto esito negativo o no, nessun altro dettaglio (eccetto se è colpa dell'utente o del server).