Web Api için neden WSDL türü desteği yok?

Bu yüzden sadece yeni Net NetAAP ile başlıyorum ve hemen fark ettiğim bir şey, API'nin nasıl göründüğünü ve tüketilmesi gerektiğini tanımlayan bir Sözleşme olmamasıdır (Her bir Eylemden İstek / Cevaplar), bu genellikle WCF / Sabun için bir WSDL.

Bana öyle geliyor ki, çok değerli olacak ve API'nizin tüketicileri için hayatı çok daha kolaylaştıracak bir şey.

Olmamasının bir sebebi var mı? Bilmediğim bir programlama paradigması veya ilkesi var mı? Bir tane yaratmamın bir yolu var mı?

SABUN, REST VE İNSANLARIN YARATICILIĞI

SOAP, WSDL gibi bir açıklama belgesine ihtiyaç duyuyor, çünkü her kaynak farklı mesajlarla tüketilebiliyor, protokolde bir kaynağı işleyebilecek olası adlar / mesajların kısıtlamaları hakkında bir tanım yok.

Örneğin, SOAP’te müşterilerin bir kullanıcıyı manipüle etmesine izin veren web servisiniz, bir kullanıcı oluşturan işlemi birçok mesajda açığa çıkarabilir, örneğin:

addUser
createUser
insertUser

Tabii ki, bunlar sadece birkaç örnek mesaj, çünkü çok sayıda komik web servis metodu adı görüyorum. Orada gerçekten yaratıcı insanlar var.

Öte yandan, temel sisteminizi REST prensiplerine gerçekten saygı duyan web api kullanarak ifşa ediyorsanız, müşterinin sadece Kullanıcılar adlı bir kaynağa sahip olduğunu bilmesi gerekir, çünkü bu konuda bir kullanıcı yaratma şansınızın% 99’u vardır. yol

POST /Users

Ve bu SOAP veya bir web api REST kullanarak göstermek istediğiniz her işlem için gerçekleşir.

SOAP olmasına rağmen, yapamadıklarınızı veya yapamadıklarınızı kısıtlayan bir protokol ve REST, bir şeyler yapmanın birçok açık noktasını bırakan bir stil mimarisidir. REST web apis'lerinin nasıl ortaya çıkarılacağı ve tüketileceği ile ilgili sözleşmelerin tanımlanması için çabalar vardır.

WEB API RESTİ TANIMI

Bir web api REST'in nasıl tanımlanacağı alanında Swagger'dan bahsedebilirim . Api REST web gibi bir WSDL oluşturma denemesi değildir, ancak web apis REST'i tanımlamak için açık bir standart oluşturma iyi bir girişimdir.

Swagger, RESTful web servislerini tanımlamak, üretmek, tüketmek ve görselleştirmek için kullanılan bir şartname ve eksiksiz çerçeve uygulamasıdır.

Swagger'ı çok kullanıyorum ve gerçekten seviyorum, çünkü özellikle web api'niz için güzel bir canlı konsol ve dokümantasyon oluşturmanıza izin veren Swagger UI .

Birçok dilde Swagger'ın birçok uygulaması vardır: C #, Java, Python, Ruby, vs.

ASP .NET Web API kullanıyorsanız, Swagger.NET gibi otomatik olarak Swagger özelliğini oluşturmak için bazı projeler var.

WEB API RESTESİNE ÜRETEN MÜŞTERİLER

Çünkü REST'in kısıtlamaları, sınırlı fiil grubu (GET, POST, PUT, DELETE, vb.) Gibi, bir web api REST'ına bir istemci kütüphanesi oluşturmak kadar zor değildir.

WebApiProxy gibi projeler kolaylıkla C # ve Javascript istemcileri oluşturabilir.

WEB API RESTİ İÇİN SÖZLEŞMELER

Yaşamlarımızı geliştiriciler olarak daha kolay tutmak için web api REST'in nasıl davranacağına dair bazı sözleşmeler tanımlamak iyidir, bu alanda en iyi gayret gösterdiğim Apigee - Web Api Tasarım e-kitap . E-kitap, api'nizi nasıl tasarlayacağınızla ilgili bir incil veya mantra yaratma çabası değil, Twitter, Facebook, Linkedin, Google vb.

Özetle, çünkü SOAP kendi kendini tanımlayıcı olarak tasarlandı: Bir SOAP bitiş noktası genellikle hangi işlemleri sağladığını ve verinin her bir işlemin nasıl ve / veya geri döndüğünü (gömülü XSD'ler aracılığıyla) nasıl göründüğünü açıklayan bir wsdl içerir.
Bu kendi kendini tanımlayıcı olması nedeniyle, Visual Studio gibi bir uygulamanın web sunucusu proxy'si oluşturması mümkündür.

Ayrıca, SOAP ile şifreleme veya işlem yapma davranışına izin veren birkaç SOAP uzantısı (WS- * belirtimi) vardır. Fikir, SOAP'ı kurumsal sınıf web servisleri oluşturmak için tek adresli mağazanız olarak kullanabileceğinizdir.

Diğer yandan...

WebAPI, REST hizmetleri sağlamak için tasarlanmıştır. REST'in iletişim biçimi genellikle JSON veya normal xml'dir - gerçekten önemli olmasa da, düz metin bile olabilir. REST hizmetleri tamamen farklı bir felsefeyi izler: hafif olmaları gerekir, böylece AJAX çözümünün bir parçası olarak müşteri tarafı komut dosyaları veya mobil cihazlar tarafından kolayca tüketilebilirler.
Bu nedenle, tanımlayıcılık da dahil olmak üzere tören seviyesini minimumda tutma ihtiyacı vardır. Ayrıca, REST servislerinde (JSON gibi) kullanılan iletişim biçimlerinin çoğunun içeriğini zaten tanımlamanın resmi bir yolu yoktur.

Özetle, SOAP web servislerinin genellikle çözümleri (belki de farklı) çözümlere entegre etmek için kullanıldığını, REST servislerinin de aynı çözümün parçaları arasında iletişim sağlamak için daha uygun olduğunu söyleyebilirsiniz.

SOAP / WS- * ve RESTful API'ler aynı değildir. SOAP / WS- * WSDL destekleyen API'leri oluşturmak istiyorsanız, Microsoft yığınında tercih edilen araç WCF'dir (HTTP bağlama seçeneğiyle birlikte monte edilir) (XML ve JSON bağlama seçenekleri vardır, XML WSDL'yi destekleyen seçenektir).

Uygulamada, farklı bir uygulama dilinden veya platformdan bir WSDL kullanmak sorunlu olmuştur. WS- * güvenlik katmanları üst üzerinde çok daha fazla.

Kendi deneyimlerim çoğunlukla bu konuda .Net, Node, Java ve PHP ile olmuştur ve şunu söyleyebilirim ki, bir alt türün ayrıntılarını tanımlamak zorunda olmayan platformlara sahipseniz ya da "Nesne" yi kullanacaksınız. tanımı az söylemek sorun çıkarır. Bunun ötesinde, çoğu zaman hiç kimse SOAP / WS- * 'nin çalışmasını sağlamak için büyük ölçüde alet kullanmaya dayandığını anlayamaz. Bu takımın çok fazla ek yükü var ve farklı sistemler farklı çalışıyor.

Bunlar, insanların daha basit uygulamaları denemek için aramasının sebeplerinden bazıları. REST hizmetleri (ala Web API), nesnelerin / durumların çevresinde bitiş noktaları sunar. JSON formatında temsil edilen bir dizi basit nesne yapısını ve bu yapılara karşı kullanılacak son noktaları tanımlamaktan daha kolay olduğu fikri, çalışmayan yabancı bir ortamdan WSDL kullanmaya çalışmaktan sonra kazmaya çalışmak ve sorun etrafında çalışmak.

İronik olarak, bu ben de Düğümü kullandım alanlarından biridir sürü bir istemci olarak kirli uygulamalarını kabul etmek esnek yeterince oldu ve iyi çalıştı benim adapte yük karşı basit müşterilerine yazabilirim çünkü, bir çeviri hizmeti olarak. Örn: C #, bir WSDL içe aktarma kullanamadığımda gerçekten çalıştığını tanımladığım nesne temsiline dönüştürmek için JSON.Net kullandığım JSON metnini alıyor.

Uygulamada bu çok olur.

Buradaki cevapların çoğu harika olsa da, cevabın ÇOK daha basit olduğunu düşünüyorum: iş için yanlış teknolojiye bakıyorsunuz.

Bir SOAP servisi kurmak istiyorsanız, gerçekten WCF'e bağlı kalmalısınız. Hala çok güçlü bir çerçeve, Microsoft hala aktif olarak geliştiriyor, gelecekte herhangi bir yere gideceğini düşünmemiz için hiçbir duyuru yapılmadı ve bu akılda tutularak yapıldı. Web API hiçbir şekilde WCF'nin yerini almaz (muhtemelen WCF'den daha lider olmasına rağmen).

Web API eskiden WCF'nin bir parçasıydı, ancak ASP.NET ailesine taşındı, çünkü kesinlikle WCF teknolojilerine uymuyordu. Web API, HTTP'yi bir protokolden ziyade bir uygulama protokolü olarak kullanmakla ilgilenmektedir. Web API'sinde HTTP fiilleri kraldır, WCF'de HTTP sadece SOAP protokolünü etkinleştirmeye yarar.

Web API'sini, yapılmayan bazı şeyleri yapma yeteneği vermediği için suçlamayın.