I miei due centesimi sull'utilizzo dell'interfaccia IHttpActionResult in WebAPI

L'API Web di Microsoft è stata per un po 'di tempo il framework di scelta per la creazione di servizi RESTful che possono funzionare su HTTP. L'interfaccia IHttpActionResult è stata introdotta con WebAPI versione 2 e fornisce un modo diverso per inviare risposte dai metodi del controller WebAPI e utilizza async e await per impostazione predefinita.

Essenzialmente, IHttpActionResult è una factory per HttpResponsemessage. L'interfaccia IHttpActionResult è contenuta nello spazio dei nomi System.Web.Http e crea un'istanza di HttpResponseMessage in modo asincrono. IHttpActionResult comprende una raccolta di risposte incorporate personalizzate che includono: Ok, BadRequest, Exception, Conflict, Redirect, NotFound e Unauthorized.

L'interfaccia IHttpActionResult contiene un solo metodo. Ecco come appare questa interfaccia:

namespace System.Web.Http

{

    public interface IHttpActionResult

    {

        Task ExecuteAsync(CancellationToken cancellationToken);

    }

}

È possibile restituire una risposta personalizzata utilizzando uno dei metodi di supporto della classe ApiController elencati di seguito.

Ok

NotFound

Exception

Unauthorized

BadRequest

Conflict

Redirect

InvalidModelState

Restituzione della risposta dai metodi del controller WebAPI

In questa sezione esploreremo come possiamo sfruttare IHttpActionResult per inviare risposte dai metodi del controller.

Ora, considera il seguente controller WebApi:

public class DefaultController : ApiController

    {

        private readonly DemoRepository repository = new DemoRepository();

        public HttpResponseMessage Get(int id)

        {

            var result = repository.GetData(id);

            if (result != null)

                return Request.CreateResponse(HttpStatusCode.OK, result);

            return Request.CreateResponse(HttpStatusCode.NotFound);

        }

    }

Si noti che in ogni caso viene restituito il codice di stato appropriato, ovvero, se i dati sono disponibili, viene restituito HttpStatusCode.OK mentre viene restituito HttpStatusCode.NotFound se i dati non sono disponibili.

Vediamo ora come è possibile modificare lo stesso metodo del controller per restituire la risposta come IHttpActionResult. Ecco il codice aggiornato del metodo del controller come riferimento. Nota come HttpResponseMessage è stato sostituito con IHttpActionResult.

public IHttpActionResult Get(int id)

        {

            var result = repository.GetData(id);

            if (result == null)

                return NotFound();

            return Ok(result);

        }

Fare riferimento al metodo Get indicato sopra. Il codice è molto semplice e snello e astrae il modo in cui il messaggio Http è effettivamente costruito nel controller. Ed ecco un altro esempio.

Fare riferimento al frammento di codice seguente che restituisce HttpResponseMessage per segnalare l'esito positivo o negativo.

public HttpResponseMessage Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

               return new HttpResponseMessage(HttpStatusCode.OK);

            return new HttpResponseMessage(HttpStatusCode.NotFound);

        }

Ora guarda come lo stesso metodo di azione può essere refactored usando IHttpActionResult per rendere il codice molto più snello e semplice.

public IHttpActionResult Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

              return Ok();

            return NotFound();

        }

Quale dovrei usare e perché?

Quindi, dovremmo usare IHttpActionResult su HttpResponseMessage nei nostri controller WebAPI quando restituiamo le risposte? Ecco la mia risposta a questa domanda. Preferirei sempre IHttpActionResult su HttpResponseMessage poiché così facendo, il test dell'unità dei controller diventerebbe semplificato. È possibile spostare la logica comune per la creazione di risposte Http ad altre classi e rendere i metodi del controller snelli e semplici. In sostanza, i dettagli di basso livello della creazione delle risposte Http sarebbero incapsulati.

In una nota diversa, vale la pena ricordare che nell'utilizzo di IHttpActionResult, è possibile aderire al principio di responsabilità unica così come i metodi di azione possono concentrarsi sulla gestione delle richieste Http piuttosto che costruire i messaggi di risposta HTTP. C'è un altro punto degno di nota. Puoi sfruttare IHttpActionResult per fornire supporto per HTML con Razor. Tutto quello che devi fare è creare un risultato di azione personalizzato in grado di analizzare le visualizzazioni Razor. La creazione di un risultato di un'azione personalizzata è semplice. Dovresti solo estendere l'interfaccia IHttpActionResult e quindi implementare la tua versione del metodo ExecuteAsync.