Mengapa saya harus menggunakan IHttpActionResult daripada HttpResponseMessage?

Saya telah mengembangkan dengan WebApi dan telah pindah ke WebApi2 di mana Microsoft telah memperkenalkan IHttpActionResultAntarmuka baru yang tampaknya direkomendasikan untuk digunakan daripada mengembalikan a HttpResponseMessage. Saya bingung tentang kelebihan dari Antarmuka baru ini. Tampaknya terutama hanya menyediakan cara yang sedikit lebih mudah untuk membuat HttpResponseMessage.

Saya akan mengajukan argumen bahwa ini adalah "abstraksi demi abstraksi". Apakah saya melewatkan sesuatu? Apa keuntungan dunia nyata yang saya dapatkan dari menggunakan Antarmuka baru ini selain mungkin menghemat satu baris kode?

Cara lama (WebApi):

public HttpResponseMessage Delete(int id)
{
    var status = _Repository.DeleteCustomer(id);
    if (status)
    {
        return new HttpResponseMessage(HttpStatusCode.OK);
    }
    else
    {
        throw new HttpResponseException(HttpStatusCode.NotFound);
    }
}

Cara Baru (WebApi2):

public IHttpActionResult Delete(int id)
{
    var status = _Repository.DeleteCustomer(id);
    if (status)
    {
        //return new HttpResponseMessage(HttpStatusCode.OK);
        return Ok();
    }
    else
    {
        //throw new HttpResponseException(HttpStatusCode.NotFound);
        return NotFound();
    }
}

Anda mungkin memutuskan untuk tidak menggunakan IHttpActionResultkarena kode Anda yang ada membuat kode HttpResponseMessageyang tidak cocok dengan salah satu dari tanggapan kalengan. Namun Anda dapat beradaptasi HttpResponseMessagedengan IHttpActionResultmenggunakan respons kalengan ResponseMessage. Butuh beberapa saat untuk memikirkan ini, jadi saya ingin mempostingnya yang menunjukkan bahwa Anda tidak harus memilih satu atau yang lain:

public IHttpActionResult SomeAction()
{
   IHttpActionResult response;
   //we want a 303 with the ability to set location
   HttpResponseMessage responseMsg = new HttpResponseMessage(HttpStatusCode.RedirectMethod);
   responseMsg.Headers.Location = new Uri("http://customLocation.blah");
   response = ResponseMessage(responseMsg);
   return response;
}

Catatan, ResponseMessageadalah metode kelas dasar ApiControlleryang harus diwarisi oleh pengontrol Anda.

Anda masih bisa menggunakan HttpResponseMessage. Kemampuan itu tidak akan hilang. Saya merasakan hal yang sama seperti Anda dan berdebat secara luas dengan tim bahwa tidak ada kebutuhan untuk abstraksi tambahan. Ada beberapa argumen yang dilontarkan untuk mencoba dan membenarkan keberadaannya tetapi tidak ada yang meyakinkan saya bahwa itu berharga.

Begitulah, sampai saya melihat sampel ini dari Brad Wilson . Jika Anda membangun IHttpActionResultkelas dengan cara yang bisa dirantai, Anda memperoleh kemampuan untuk membuat pipa respons "tingkat tindakan" untuk menghasilkan HttpResponseMessage. Di bawah selimut, ini adalah bagaimana ActionFiltersdiimplementasikan Namun, pemesanan mereka ActionFilterstidak jelas ketika membaca metode tindakan yang merupakan salah satu alasan saya bukan penggemar filter tindakan.

Namun, dengan membuat sesuatu IHttpActionResultyang secara eksplisit dapat dirantai dalam metode tindakan Anda, Anda dapat menyusun semua jenis perilaku yang berbeda untuk menghasilkan respons Anda.

Berikut adalah beberapa manfaat dari IHttpActionResultlebih HttpResponseMessagedisebutkan dalam Dokumentasi Microsoft ASP.Net :

• Unit yang disederhanakan menguji pengontrol Anda.
• Memindahkan logika umum untuk membuat respons HTTP ke dalam kelas yang terpisah.
• Menjadikan maksud tindakan pengontrol lebih jelas, dengan menyembunyikan detail tingkat rendah dari membangun respons.

Tetapi di sini ada beberapa keuntungan lain menggunakan IHttpActionResultlayak disebut:

• Menghormati prinsip tanggung jawab tunggal : menyebabkan metode tindakan memiliki tanggung jawab melayani permintaan HTTP dan tidak melibatkan mereka dalam membuat pesan respons HTTP.
• Implementasi yang berguna sudah didefinisikan dalam System.Web.Http.Hasil yaitu: Ok NotFound Exception Unauthorized BadRequest Conflict Redirect InvalidModelState( tautan ke daftar lengkap )
• Menggunakan Async dan Menunggu secara default.
• Mudah membuat ActionResult sendiri hanya dengan menerapkan ExecuteAsyncmetode.
• Anda dapat menggunakan ResponseMessageResult ResponseMessage(HttpResponseMessage response)untuk mengonversi HttpResponseMessage ke IHttpActionResult .

// this will return HttpResponseMessage as IHttpActionResult
return ResponseMessage(httpResponseMessage); 

Ini hanya pendapat pribadi saya dan orang-orang dari tim API web mungkin dapat mengartikulasikannya dengan lebih baik tetapi ini adalah 2c saya.

Pertama-tama, saya pikir ini bukan pertanyaan satu sama lain. Anda dapat menggunakan keduanya tergantung pada apa yang ingin Anda lakukan dalam metode aksi Anda, tetapi untuk memahami kekuatan sesungguhnya dari IHttpActionResult, Anda mungkin akan perlu langkah di luar metode-metode penolong nyaman ApiControllerseperti Ok, NotFound, dll

Pada dasarnya, saya pikir kelas menerapkan IHttpActionResultsebagai pabrik HttpResponseMessage. Dengan pola pikir itu, sekarang menjadi objek yang perlu dikembalikan dan pabrik yang memproduksinya. Dalam pengertian pemrograman umum, Anda dapat membuat objek sendiri dalam kasus-kasus tertentu dan dalam kasus-kasus tertentu, Anda memerlukan pabrik untuk melakukan itu. Sama disini.

Jika Anda ingin mengembalikan respons yang perlu dibangun melalui logika yang kompleks, katakan banyak header respons, dll, Anda dapat mengabstraksi semua logika tersebut menjadi kelas hasil tindakan yang diterapkan IHttpActionResultdan menggunakannya dalam berbagai metode tindakan untuk mengembalikan respons.

Keuntungan lain menggunakan IHttpActionResultsebagai tipe pengembalian adalah membuat metode tindakan ASP.NET Web API mirip dengan MVC. Anda dapat mengembalikan hasil tindakan apa pun tanpa terjebak dalam pembuat format media.

Tentu saja, seperti dicatat oleh Darrel, Anda dapat mengaitkan hasil tindakan dan membuat pipa mikro yang kuat mirip dengan penangan pesan sendiri di pipa API. Ini akan Anda butuhkan tergantung pada kompleksitas metode tindakan Anda.

Singkat cerita - tidak IHttpActionResultberbanding terbalik HttpResponseMessage. Pada dasarnya, ini adalah bagaimana Anda ingin membuat respons. Lakukan sendiri atau melalui pabrik.

Web API pada dasarnya kembali 4 jenis objek: void, HttpResponseMessage, IHttpActionResult, dan jenis kuat lainnya. Versi pertama dari API Web kembali HttpResponseMessageyang cukup lurus ke depan pesan respon HTTP.

Itu IHttpActionResultdiperkenalkan oleh WebAPI 2 yang merupakan semacam bungkus HttpResponseMessage. Ini berisi ExecuteAsync()metode untuk membuat HttpResponseMessage. Ini menyederhanakan pengujian unit controller Anda.

Jenis pengembalian lainnya adalah jenis kelas mengetik yang kuat yang diserialisasi oleh API Web menggunakan formatter media ke dalam badan respons. Kekurangannya adalah Anda tidak dapat langsung mengembalikan kode kesalahan seperti 404. Yang dapat Anda lakukan hanyalah melempar HttpResponseExceptionkesalahan.

Saya lebih suka mengimplementasikan fungsi antarmuka TaskExecuteAsync untuk IHttpActionResult. Sesuatu seperti:

    public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
    {
        var response = _request.CreateResponse(HttpStatusCode.InternalServerError, _respContent);

        switch ((Int32)_respContent.Code)
        { 
            case 1:
            case 6:
            case 7:
                response = _request.CreateResponse(HttpStatusCode.InternalServerError, _respContent);
                break;
            case 2:
            case 3:
            case 4:
                response = _request.CreateResponse(HttpStatusCode.BadRequest, _respContent);
                break;
        } 

        return Task.FromResult(response);
    }

, di mana _request adalah HttpRequest dan _respContent adalah payload.

Kami memiliki manfaat menggunakan IHttpActionResultlebih dari HttpResponseMessage:

1. Dengan menggunakan IHttpActionResultkami hanya berkonsentrasi pada data yang akan dikirim bukan pada kode status. Jadi di sini kodenya akan lebih bersih dan sangat mudah dirawat.
2. Pengujian unit dari metode pengontrol yang diterapkan akan lebih mudah.
3. Penggunaan asyncdan awaitsecara default.