Asp.NET Web API Response’larında Tutarlılığı (Consistency) Sağlamak

Bunlar da hoşunuza gidebilir...

11 Cevaplar

  1. Caner dedi ki:

    Merhaba, yazınız için teşekkürler ancak test amaçlı bir deneme proje yazmıştım ve aynı projede ekstreden birde outputCache uygulamıştım ve yukarıda ki implementasyonlardan sonra projeyi çalıştırdığımda ilk requestten sonra cache duration içerisinde gelinen diğer requestlerde MessageHandler içerisindeki if(response.TryGetContentValue(out content) geriye content i null veriyor. Sebep olarak ise response içerisindeki Content alanında artık controller dan dönen obje değilde onun ram de tutulan byteContent hali bulunmakta. Bu nedenle ApiResponse objesindeki Result alanı cacheden objeyi alamadığı için client’a null gidiyor. Konu ile ilgili bir çözüm öneriniz var mıdır ?

    • Gökhan Gökalp Gökhan Gökalp dedi ki:

      Merhaba, bu konuyu test edip en kısa sürede yanıt vermeye çalışacağım. Şu link‘ide incelemenizi tavsiye ederim Web API’da output caching için. Çünkü Web API’ın buil-in olarak bir OutputCache attribute’üne sahip değil. Tamamen stateless bir yapıda inşa edildiği için.

  2. Ahmet Kurt dedi ki:

    Merhaba,

    Bu site bile tek başına mükemmel bir kaynak. Çıkaracağınız kitabı hayal bile edemiyorum. 🙂

    Makale ve paylaşım için çok teşekkürler.

  3. Burhan dedi ki:

    Merhaba hocam,
    Ben ApiController içerisinde Task Get(int id) şeklinde bir action kullanıyorum. id değerli veri bulunamaz ise NotFound() return ediyorum. Bu yöntemi uyguladığımda NotFound() sonucunda
    { Version: “1.0”, StatusCode: 404 } şeklinde sonuç veriyor. ErrorMessage kısmı gelmiyor. Bulunamadı şeklinde bir hata mesajı verdirmek nasıl olur acaba teşekkürler.

    • Gökhan Gökalp Gökhan Gökalp dedi ki:

      Merhaba, error kısmı için benim oluşturmuş olduğum herhangi bir exception gerçekleştiğinde alınacak message kısmı. Eğer bulunamadı gibi custom message’lar dönmek istiyorsanız ErrorMessage dışında sizde bir message property’si tanımlayıp, ilgili durum bilgilerini oradan expose edebilirsiniz.

  4. Yunus Emre dedi ki:

    Sizce Best Practice hangisi olur :

    -HTTP Status Code’lara göre hata kodlarımızı belirlemek mi ? (Buradaki dezavantaj eğer HTTP Status Code listesinde olmayan, sisteme göre bambaşka bir kod kullanılacaksa, bunu dönememek olur sanırım)
    -Custome Code yapısı oluşturup bu code’ları mı dönmek ? (Burada da, zaten HTTP Status Code listesinde tanımlı kodları tekrar tanımlamak ve karşı tarafın da bu listeden haberdar olmak zorunda olması dezavantaj sanırım)

    • Gökhan Gökalp Gökhan Gökalp dedi ki:

      Merhaba,

      Açıkcası bu konu biraz karışık. Tamamen kurumunuzun kararlarına göre değişiklik gösterebilir aslında. Olması gereken standart olarak HTTP Status code’larına göre davranmak olacaktır elbette (bana göre). Tabi gerçek anlamıyla RESTful kafası ile design yapıyorsak. Eğer bunu yapıyorsak da, RESTful’a göre response’ları wraplememek gerekir aslında. Consistency için wraplemek de ayrı bir karar. O yüzden kendi kurumunuzun kendisine has tailored bir şekilde belirlediği bir standart olmalıdır derim gerek wrapping, gerekse de HTTP Status Code’larına göre veya custom olarak kendi rule’ları ile hataları belirlemek. Tamamen tercih diyebilirim. Birde bu API’ın nereye hizmet edeceği ile de alakalı bir konu.

      • Yunus Emre dedi ki:

        Kurumun bu konuda almış olduğu bir karar yok ama şunu söyleyebilirim istekte bulunacak tüm client uygulamalar da kurum tarafından yazılacak.

        Yine de benim de isteğim standartlara mümkün olduğunca uymaktan yana. Bu doğrultuda HTTP Status Code listesini kullanıp ama birkaç metot için HTTP Status Code listesinde olmayan bir kod dönme ihtiyacı olursa nasıl bir yol izlemek lazım var mı kabul görmüş bir seçenek ?

        • Gökhan Gökalp Gökhan Gökalp dedi ki:

          Yalnız buradaki status code kavramlarını da karıştırmayalım. En basitinden size gelen bir requestteki işlem, gerçekleşemese bile aslında bunun status code’u 200’dür. Çünkü sunucuya başarılı bir şekilde gelip, business’sal işlemlerden dolayı gerçekleşememiştir. Bunları iyi ayırt etmek gerek. Siz ise wraplediğiniz context üzerinde farklı bir statu kodları elbette kullanabilir, error message’ları da karşıya iletebilirsiniz. Ben şu ana kadar tek bir doğrusunu görmedim bu işin.

  5. cem basaranoglu dedi ki:

    Merhabalar,

    Bu Api response unu consistency icin wrap etme yaklasimi oldukca basarili fakat ModelState validation resultlari icin bu wrapping dogru bir bicimde calisir mi ? Bence direkt objenin namespaceini response a ekler gibi duruyor.

    iyi calismalar

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*