ASP.NET Core’da OData ile Çalışmak

OData’ya Giriş

Onu tasarlayanlara göre OData (açık veri protokolü), “REST olmanın en iyi yoludur”.

REST, bildiğiniz gibi bir mimari tarzdır. İstemci-sunucu etkileşiminin durumsuz olması gerektiği, her mesajın mesajın nasıl işleneceğini açıklayan yeterli bilgiyi içermesi gerektiği gibi, bize bir dizi kısıtlama ve alt kısıtlama sağlar.

Ancak REST bir standart değildir. Bunun yanı sıra, biz geliştiricilere karar vermemiz için epeyce açık bırakıyor. Örneğin, kaynak adlandırma yönergelerini alın. Şüphesiz “api/employee/1” (tekil isim yaklaşımı), “api/employees/1” (çoğul isim yaklaşımı), “api/anlamsızisim/1” veya “api/nomeaning/123/eşsizanlam” gibi kaynaklar görmüşsünüzdür. /234″ – bu örneklerin tümü, aynı çalışan kaynağına başvurmanın yolları olabilir.

REST ile uyumlu olmakla birlikte, özellikle üzerinde çalıştığınız proje tüm bu farklı kaynak adlandırma stillerinin bir karışımından oluştuğunda, bunlardan bazıları tam olarak geliştirici dostu değildir. Bu sadece basit bir örnek. HATEOAS gibi bir kez daha egzotik kısıtlamaların RESTful sisteminizde uygulanması gerekiyor ve bu kısıtlamalar için sözleşmelerin nasıl tanımlanacağına karar verilmesi yoruma daha da açık oluyor.

OData burada devreye giriyor. OData, esasen, REST’i denemenin ve standartlaştırmanın bir yoludur. Sorgulanabilir ve birlikte çalışabilir RESTful API’lerinin basit ve standart bir şekilde oluşturulmasına ve tüketilmesine izin veren açık bir protokoldür. Hangi tür istek için hangi HTTP yönteminin kullanılacağı, hangi durum kodlarının ne zaman döndürüleceği gibi şeyleri açıklar, ayrıca: URL kuralları.

Ayrıca, verileri sorgulama – filtreleme ve sayfalama ile ilgili bilgileri de içerir, ayrıca: özel işlevleri ve eylemleri çağırma, toplu isteklerle çalışma ve daha fazlası.

Mevcut sürüm 2 ana bölümden oluşan v4’tür.

Bölüm 1, kullanılacak başlıkların açıklamalarını, olası yanıt kodlarını, bir varlığın ne olduğuna ilişkin tanımları, bir tekil, türetilmiş, genişletilmiş veya yansıtılmış varlıklar vb., bir istek ve yanıtın nasıl görünmesi gerektiği de dahil olmak üzere protokolün kendisidir.

Bölüm 2, tamamen bu URL kurallarıyla ilgilidir.

Bu makalenin bir kısmı, şirketlerin OData uygulama çerçevelerini benimsemesinin ana itici güçlerinden biri olan verileri kolayca sorgulama yeteneği ile ilgilenecektir. Bunu etkinleştirmek için, sorgu verisi için bir URL’nin nasıl görünmesi gerektiği konusunda anlaşmak önemlidir. Standardın bu bölümünde açıklanan şey budur.

Ön Koşullar – Doğru NuGet Paketlerini Ekleme

Yeni bir API projesine başladıktan sonra yapmak isteyeceğiniz ilk şey, gerekli OData NuGet paketini eklemektir. İstediğiniz Microsoft.AspNetCore.OData’dır. Bu, .NET Core ve .NET 5 için desteklenmektedir. Paketin 7.x sürümü .NET Core içindir, 8.x sürümü .NET 5 içindir. Yazma anında, .NET 5 sürümü hala içindedir. önizleme modu, ancak büyük olasılıkla siz bunu okurken önizleme dışında olacak. Bu makaleye hazırlanırken ve OData kursumu yenilerken hem 7.x hem de 8.x paketleri ile çalıştım ve farklar kesinlikle minimum düzeyde. Bu makale için .NET 5 sürümünü kullanacağım, ancak burada okuyacaklarınız aksi belirtilmedikçe her ikisi için de geçerlidir.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.