.net Core Web Api ( Kenan Yildirim anlatımından resmedilmiştir)
6 .net core projesi program cs içeriği
7 .net core projesi startup cs icerigi
8 kestrel web server
9 web api projemiz post get
10 web api projemiz get id ile
RESİMLERDEKİ YAZILAR
Neden ben bir projeji servis mimarisi(SOA) ile geliştirmeliyim. SOA( service oriented architecture )
İş yerim benden bir web projesi istedi. DB hazırladım. SOLID prensiplerine uygun olarak, Katmanlı mimariye dayalı yapımı da hazırladım. IIS ya da Apache serverda bunu yayınladım ve kullanıcılar kullanmaya başladılar.
Sonra müşterimiz bu uygulamayı Android ve IOS ortamı için de istedi. Biz de katmanlarımızı kopyaladık ve kolaylıkla mobile uyumlu hale getirdik. Ancak sorun şu ki, yapılan güncellemeler iki taraf için de yeniden işleme tabi tutulması gerekiyor. Yani bir tarafta yaptığımızı öbür tarafta da yapmamız gerekiyor. Bu sürdürülebilir değil.
Web servisler ile Tier architecture yapısını uygulamış oluyoruz: Servislerimi arayüzlerden ayrı yerde tutuyorum. Değişiklik olduğunda tek bir yerde değiştiriyorum. Onu kullananlar değişmiş oluyor.
Diğer yönü teknolojiden bağımsız hale geldim. Servisi ister php, ister java, ister phyton ile yazayım farketmez.
Web UI ve Mobile UI yı da hangi teknoloji ile geliştirdiğimin önemi kalmamış oluyor.
Yani
1-Tek bir yerden yönetmiş oldum
2-Teknoloji bağımsızlığını kazandım
biz SOA teknolojilerinden Restful Servicesleri kullanacağız. Restful Serviceslerden de .Net Core Web Api ile post, get, put vs kullanarak işlemler yapacağız.
Rest Api: farklı platformlar arasında metot paylaşımı sağlamak. İlk zamanlar yalnızca bilgisayarlar yeterli olurken, günümüzde birçok farklı cihaz oluşturulan metotları kullanma ihtiyacı duyuyor.
***********
Bunlar birbirinden bağımsız iki framework. Yani birinde yazdığımız dll, diğerinde çalışmayacaktır. Windows bu sorunu çözmek için .Net Standard ı geliştirdi. Arabulucu gibi düşünebiliriz.
.Net Framework de biz yalnızca windows ortamında geliştirme yapabiliyoruz. Ve geliştirdiğimiz uygulamaları win ortamında yani IIS serverda yayınlayabiliyoruz.
.Net Core: ortam bağımsız geliştirme yapılmasına imkan veriyor. Ve istediğimiz serverda yayınlayabiliyoruz. iste win (IIS) olsun ister linux (örn: apache) farketmiyor.
.Net Core da 3 farklı proje tipine ayrılıyor. Mvc ve Web Api projeleri birbirine çok benziyor. Aralarındaki tek fark, mvc de geriye return view döndürüyoruz, web api de ise return json diyoruz.
***************
Main metodu programımızın başlangıç noktası. Buradaki CreateHostBuilder metodu, .net uygulamalarını yayınlayabilmek için bi server ayağa kaldırıyor. Bu serverın ismi Kestrel Web Server.
Yani server Build metodu ile hazır hale getiriliyor. Run metodu ile de çalıştırılıyor.
Bi konfigürasyon dosyası verilmeli ki değişiklik yapacağı zaman onun içinde yapsın. Bunun için startup classı veriliyor. Biz de server ile alakalı ayarlamalar yapacağımız zaman startup classı içinde yapacağız.
************
startup classı içinde 2 tane metot var. ConfigureServices ve Configure metotları.
Bunlardan ilk olarak ConfigureServices çalışır. Burası, uygulamamızı ihtiyacımıza göre yapılandırmamızı sağladığımız yerdir. Kimisi mvc ile devam etmek ister. kimisi web api ile. Bunları dahil ettiğimiz yerdir. .Net Core burada bize büyük bir özgürlük veriyor. Kim neyi kullanmak istiyorsa onu ekliyor.
Configure metodu ise Request lerimizi yönetmemizi sağlıyor.
Benim tüm requestlerim IIS servera gidiyor. ISS server bunları Kestrel servise aktarıyor. Kest Core uygulamamla iletişime geçiyor. Oradan bir response dönüyor. Bu response Kest den ISS e aktarılıyor. O da kullanıcıya gösteriyor.
Burada akla gelen soru: neden burada IIS e gerek var. Ben requestimi direk Kestrel e yapamaz mıyım?
Çünkü kestrel web server, IIS ya da Apache servera göre çok basit bir web server. ONlarda bulduğumuz özellikleri kest de bulamayız. Örneğin ISS bütün requestleri loglar. Kestrelde böyle bir özellik yok.
*******
Api projelerimizde Route larımız genelde api ile başlar. Bundan dolayı biz de böyle başladık.
/controller dedik. böylece controllerım adı ne ise o isimle buraya ulaşılabilir.
Projemizi çalıştırdıktan sonra adres çubuğuna:
localhost/64940/api/users
yazdığımızda Get metodu çalışır ve ekrana Get Users yazdırılmış olur.
*************
birşey yazılmadığı zaman default olarak HttpGet olarak kabul eder.
Burada HttpGet olduğunu belirttik ve bir de id isimli parametre alacağını belirttik.
localhost/64940/api/users/10 yazdığımızda id=10 şeklinde işlemi yapacaktır.
Bu metodları chrome ile test edebildik. Ama post, put ve delete işlemlerini yaptığımızda tarayıcı bize yetmeyecek. Bunlar için postman kullanacağız.
*******
Postman de POST metodunu seçtikten sonra Header bölümünde Content-Type özelliğini text/plain yerine application/json olarak değiştiriyoruz.Çünkü veri kümemiz json formatına uygun.
PUT seçip işlem yaptığımızda ise Put isimli metodumuz çalışacaktır.
********
/// yazdığımızda otomatik olarak summary alanı gelir. Bu alan metotlarımızı, Postman ya da Swagger gibi ortamlar üzerinden test etmek isteyen kullanıcılarımız için açıkladığımız bölümdür.
Yorumlar
Yorum Gönder