Linux'ta .NET Aspire'da DELETE Endpoint Ekleme

DELETE Uç Noktasını Eşleme

[1:02 - 2:14] Uç nokta kaydı, diğer yollarla aynı şekli takip eder, ancak iki ayarlama ile. Rota, kimliğin gövdeden ziyade URL'de geçirilmesi için {id:int} segmenti içerir ve işleyici imzası MapPost veya MapPut yerine MapDelete kullanır. Hiçbir giriş kaydı yoktur çünkü tanımlayıcıdan başka bir şeye ihtiyaç yoktur.

app.MapDelete("/api/tickets/{id:int}",
    async Task<Results<NoContent, ValidationProblem>>
    (ISqlDataAccess sql, int id) =>
{
    await sql.SaveDataAsync("dbo.spTickets_Delete",
        new { Id = id }, "TicketDB");
    return TypedResults.NoContent();
});

app.MapDelete("/api/tickets/{id:int}",
    async Task<Results<NoContent, ValidationProblem>>
    (ISqlDataAccess sql, int id) =>
{
    await sql.SaveDataAsync("dbo.spTickets_Delete",
        new { Id = id }, "TicketDB");
    return TypedResults.NoContent();
});

İşleyici, Dapper sarmalayıcı üzerinden spTickets_Delete saklı yordamını çağırarak kimlik ile anonim bir nesne geçirir. TypedResults.NoContent() döndürmek, işlemin başarılı olduğunu ve döndürülecek bir yanıt gövdesi olmadığını belirten 204 durumu üretir. Dönüş türü beyanı, önceki bölümün PUT uç noktasına ayna tutar, çünkü her iki işlem de çerçeveden mümkün olan aynı sonuçlar kümesine sahiptir.

Parametre Büyük/Küçük Harf Uyumsuzluğunu Düzeltme

[2:14 - 4:32] DELETE çağrısını bağlarken, Tim seride daha önce tanıttığı bir uyumsuzluk fark eder. spTickets_Delete saklı yordamı, anonim nesneye açık bir Id = id ataması gerektiren büyük harf Id parametresi kullanır. spTickets_Update yordamı da büyük harf Id kullanır. Ancak ID'ye göre GET uç noktasının arkasındaki spTickets_Get, küçük harf id kullanır. Bu küçük harfli varyant, orijinal işleyicinin new { id }'u açık atama olmadan geçirmesine izin verdi, bu o zaman uygun görünüyordu ama kod tabanını tutarsız bıraktı.

Asimetrik durumu ileri taşımaktansa, SQL Server Management Studio'yu açar ve GET yordamını büyük harf Id kullanacak şekilde değiştirir:

ALTER PROCEDURE spTickets_Get
    @Id int
AS
BEGIN
    SELECT Id, Title, Description, DateCompleted, Priority, CreatedDate
    FROM dbo.Tickets
    WHERE Id = @Id;
END

Yordam güncellenmişken, Program.cs içindeki GET işleyicisi artık DELETE ve PUT işleyicilerinin kullandığı aynı açık eşlemeye ihtiyaç duyar ve new { id } yerine new { Id = id }'ye değişir. Değişiklik mekanik olsa da, sebep önemlidir: saklı prosedürler arasında tutarlı parametre büyük/küçük harf sıralaması, her uç noktanın parametreleri aynı şekilde bağladığı anlamına gelir, bu da daha sonra veri erişim katmanını okurken küçük ama gerçek bir karışıklık kaynağını ortadan kaldırır. Yalnızca dört yerden birinde tutulan bir kural bir kural değildir.

Eksik Kayda 204 vs. 404 Döndürüleceği Zaman

[4:46 - 5:46] Uç nokta derlendikten sonra, Tim her DELETE uygulamasında ortaya çıkan bir tasarım sorusu üzerinde durur. Eğer arayan var olmayan bir ID geçerse, API ne döndürmelidir? İki makul cevap vardır.

Hiçbir satırın silinip silinmediğine bakmaksızın 204 NoContent döndürmek isteği idempotent olarak ele alır. Arayanın bakış açısından, kaynak gitmiştir, bu hedefti. Mevcut işleyici tam da bunu yapar ve Tiny Ticket projesi bununla gönderilecektir. Eksik bir kayıt için 404 NotFound geri döndürmek arayana daha fazla bilgi verir ancak saklı prosedürün aslında bir satırın silinip silinmediğini raporlamasını gerektirir; bu genellikle işleyicinin hangi yanıtı göndereceğine karar vermeden önce inceleyebileceği bir satır sayısı ile döndürülür.

Ön ucun zaten hangi ID'lerin mevcut olduğunu bildiği bir iç CRUD API için (çünkü sadece listeyi yükledi), 204 yeterlidir. Arayanların ID tahmini yapabilecekleri bir public API için, 404, verilerin var olmayan bir şekilde silindiği yanıltıcı sessizlik illüzyonunu önler. Tim, 404 döndürmenin veritabanında hangi ID'lerin mevcut olduğunu sızdırabileceğini kaydeder fakat silme işlemi için pratik risk düşüktür çünkü uç noktayı kullanma zaten yazma erişimi ima eder.

Swagger Üzerinden Test Etme

[5:46 - 7:08] Veritabanı çalışır durumda, Tim API'yi başlatır ve Swagger'ı açar. Her şeyden önce GET tümünü çalıştırır ve mevcut verilerin durumunu alır: orijinal tohumdan 1, 2, 3 kayıtları ve daha önceki ekleme testlerinden kalan 107, 109, ve 110.

107 üzerinde DELETE yürütür ve 204 geri alır. 110 için de aynı. Eksik kayıt davranışını doğrulamak için, veritabanında asla olmayan 1011 üzerinde DELETE yürütür. Yanıt hala 204'tür, hiçbir şeyin silinmediğine dair bir gösterge yoktur. Bu, önceki bölümde tartışılan kar-zarar dengesidir, şimdi gerçek API yanıtında görülebilir.

İkinci bir GET tümünü çalıştırması son durumu doğrular: 1, 2, 3 ve 109 kalmıştır. DELETE uç noktası geçerli ID'ler için çalışır ve geçersiz olanlar için sessizce başarısız olur, tam da uygulama belirttiği gibi.

Tamamlamak: CRUD Tamamlandı

[7:08 - 8:38] DELETE eklemek Tiny Ticket API'si için dört CRUD fiilini tamamlar. Aynı yapısal desen her bir uç noktada taşınır: yol tanımı, saklı prosedür adı, Dapper veri erişim çağrısı, yazılan sonuç. Tim, üretim bir API'nin muhtemelen tamamlanmış bir bileti işaretlemek için bir PATCH ekleme veya bir özel arama uç noktası gibi daha fazla uç nokta ekleyeceği konusunda dürüsttür. Ancak serinin amacı, her katmanı odaklı tutmak, böylece bir sonraki katmanın (ön yüz) üzerinde çağrılar yapabileceği temiz bir yüzey sağlamaktır.

Tutarlılık, projeyi okunabilir kılan şeydir. Dapper sarıcısı, POST ekleme deseni, doğrulama hattı ve yazılı sonuçlar, her yeni uç noktanın hangi fiili uyguladığını bakmaksızın yaklaşık aynı miktarda kod almasını sağlar. Bu öngörülebilirlik, API'yi takip eden ön yüz çalışması için hoş bir hedef yapar.

Sonuç

[8:38 - 8:40] Minimal bir API'ye DELETE uç noktası eklemek, rotada ID segmentine sahip bir MapDelete kaydı, veri erişim sarmalayıcısı aracılığıyla saklı yordam çağrısı ve TypedResults.NoContent() dönüşü gerektirir. Bu uç nokta Tiny Ticket projesinin CRUD yüzeyini tamamlar ve serinin bir sonraki aşamasında ön yüze geçişi ayarlar.

Seri navigasyonu: Bu makale, Tiny Ticket uygulamasını oluşturan Linux üzerinde C# serisinin bir parçasıdır. Önceki: PUT Güncelleme Uç Noktası Ekleme. Sonraki aşama: API tüketen ön yüz sayfaları.

Örnek İpucu: Saklı yordamı değiştirmeden daha bilgilendirici bir DELETE yanıtı istiyorsanız, etkilenen satır sayısını SaveDataAsync'dan yakalayın ve sayı sıfır olduğunda bir TypedResults.NotFound() döndürün. Bu, veri erişim katmanını yeniden yapılandırmadan 404 yolunu ekler.

Onun YouTube Kanalı üzerindeki tam videoyu izleyin ve Linux serisinde C# ile CRUD uç noktaları oluşturma üzerine daha fazla bilgi edinin.