RESTful Services - WSDL Eşdeğeri

REST ve SOAP hakkında bir şeyler okudum ve REST uygulamasının neden bir SOAP protokolü kullanmaya göre daha faydalı olabileceğini anlıyorum. Ancak, REST dünyasında neden "WSDL" eşdeğeri olmadığını hala anlamıyorum. WSDL'ye "gerek olmadığını" veya bunun REST dünyasında gereksiz olacağını söyleyen gönderiler gördüm, ancak nedenini anlamıyorum. Manuel olarak kodlamak yerine programlı olarak bir tanıma bağlanmak ve proxy sınıfları oluşturmak her zaman yararlı değil mi? Felsefi bir tartışmaya girmek istemiyorum, sadece REST'te WSDL olmamasının nedenini veya neden gerekli olmadığını araştırıyorum. Teşekkürler.

Web Uygulaması Açıklama Dili (WadL) temelde RESTful servisler için WSDL eşdeğerdir ancak böyle bir şey hiç gerekli olup olmadığı, devam eden bir tartışma olmuş.

Joe Gregorio, bu konu hakkında okunmaya değer güzel bir makale yazdı .

WSDL, hizmet uç noktalarını açıklar. REST istemcileri sunucu uç noktalarına bağlanmamalıdır (yani, URL'lerde önceden haberdar olmamalıdır). REST istemcileri, istemci ve sunucu arasında aktarılan ortam türlerinde birleştirilir.

Döndürülen ortam türlerini sarmak için istemcide sınıfları otomatik olarak oluşturmak mantıklı olabilir. Ancak, hizmet etkileşimleri etrafında proxy sınıfları oluşturmaya başlar başlamaz, HTTP etkileşimlerini gizlemeye ve bir RPC modeline doğru dejenere olma riskini almaya başlarsınız.

RSDL, bir hiper ortam gibi dinlenmeyi amaçlamaktadır, başka bir deyişle, WSDL veya WADL gibi bir hizmet tanımlayıcısından daha fazla bilgiye sahiptir. Örneğin, köprü metni ve köprüler gibi gezinmeyle ilgili bilgilere sahiptir.

Örneğin, mevcut bir kaynak verildiğinde, ilgili diğer kaynaklara giden bir set os bağlantılarınız var.

Ancak, bu biçimi destekleyen Dinlenme İstemcileri veya otomatik olarak oluşturma özelliğine sahip Dinlenme Sunucusu Çözümleri bulamadım.

Bunun hakkında bir sonuca varmanın uzun bir yolu olduğunu düşünüyorum. Uzun HTML hikayesine ve W3C - Tarayıcılara karşı lol bakın.

Rest like Hypermedia hakkında daha fazla ayrıntı için bakınız: http://en.wikipedia.org/wiki/HATEOAS

Not: Roy Fielding, Rest Apis'teki bu eğilimleri hipermidya yaklaşımı olmadan eleştiriyor: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Sonuç: Şimdi bir Gün, WADL, Camel CXF gibi Rest ve Integration Framework'lerin zaten WADL'yi desteklediğinden (üret ve tüket) daha yaygındır, çünkü WSDL'ye benzer, bu nedenle bu geçiş sürecinde anlaşılması en kolay olanıdır (SOAP'tan REST'e).

Sonraki bölümlere bakalım;)

Manuel olarak kodlamak yerine programlı olarak bir tanıma bağlanmak ve proxy sınıfları oluşturmak her zaman yararlı değil mi?

İçtenlikle katılıyorum, bu yüzden Swagger.io kullanıyorum

Swagger, RESTful API'lerinizi tasarlamanıza, oluşturmanıza, belgelendirmenize ve tüketmenize yardımcı olan büyük bir araç ekosistemiyle desteklenen güçlü bir açık kaynaklı çerçevedir.

Temelde modellerimi, uç noktalarımı vb. Tanımlamak için Swagger'ı kullanıyorum ve ardından manuel olarak kodlamak yerine proxy sınıflarını oluşturmak için swagger-codegen gibi diğer araçları kullanıyorum .

Ayrıca bkz: RAML

WSDL'ye eşdeğer bir RSDL (dinlendirici hizmet tanımlama dili) vardır. Aşağıdaki URL, http://en.wikipedia.org/wiki/HATEOAS ve http://en.wikipedia.org/wiki/RSDL uygulamasını açıklamaktadır . Sorun şu ki, wsdl'den java'ya veya tersine kod üretmek için birçok aracımız var. Ancak RSDL'den kod oluşturmak için herhangi bir araç bulamadım.

WSDL, iletişim için hangi mesaj biçimleri veya ağ protokollerinin kullanıldığına bakılmaksızın uç noktaların ve bunların mesajlarının tanımlanmasına izin verecek şekilde genişletilebilir

Ancak REST, bir nesne durumunu temsil etmek için HTTP fiillerini ve URI'yi kullanarak ağ protokolünü kullanır.

WSDL'ler size bu yerde bu mesajı gönderirseniz, bu eylemi gerçekleştireceğinizi ve sonuç olarak bu biçimi geri alacağınızı söyler.

REST'te, yeni bir profil oluşturmak istersem fiili POSTbir JSON gövdesi veya profilimi URL'ye açıklayan http sunucusu değişkenleri ile kullanırdım./profile

POSTdurum kodunu 201 CREATEDve başlığı Location: *new_profile_id*(örneğin 12345) kullanarak sunucu tarafında oluşturulan bir kimlik döndürmelidir

Daha sonra , örneğin e-posta adresimi veya telefon numaramı değiştirmek gibi /profile/12345HTTP fiilini kullanma durumunu değiştirerek güncellemeler yapabilirim POST. Açıkça uzak nesnenin durumunu değiştiriyor.

GET şu anki durumunu döndürür /profile/12345

PUT genellikle istemci tarafında oluşturulan kimlik için kullanılır

DELETE, açık

HEAD, cesedi iade etmeden statüsü alır.

REST ile, iyi tasarlanmış bir API aracılığıyla kendi kendini belgelendirmeli ve dolayısıyla kullanımı daha kolay olmalıdır.

Bu, REST hakkında harika bir makale . Benim de anlamama gerçekten yardımcı oluyor.

WSDL 2.0 spesifikasyonu, REST web hizmetleri için de destek ekledi. Her iki dünyanın en iyisi senaryosu. Sorun şu ki, WSDL 2.0 henüz piyasadaki çoğu araç tarafından yaygın olarak desteklenmiyor. WSDL 2.0, W3C önerilir, WSDL1.1, W3C önerilmez ancak araçlar ve geliştiriciler tarafından yaygın olarak desteklenir. Referans: http://www.ibm.com/developerworks/library/ws-restwsdl/

Web Uygulama Açıklama Dili (WADL), RESTful web hizmetlerini tanımlamak için kullanılan bir XML sözlüğüdür.

WSDL'de olduğu gibi, genel bir istemci bir WADL dosyası yükleyebilir ve ilgili web hizmetinin tüm işlevlerine erişmek için hemen donatılabilir.

RESTful hizmetleri daha basit arabirimlere sahip olduğu için, WSDL'nin RPC tarzı SOAP hizmetleri için olduğu gibi WADL bu hizmetler için neredeyse gerekli değildir.