Neden RESTful Web Hizmetlerine ihtiyacımız var?

RESTful web servislerini öğreneceğim (CS yüksek lisans programının bir parçası olduğu için bunu yapmam gerektiğini söylemek daha iyi).

Wikipedia'da bazı bilgiler okudum ve ayrıca Sun Developer Network'te REST hakkında bir makale okudum ve bunun kolay bir teknoloji olmadığını, RESTful uygulamaları oluşturmak için özel çerçeveler olduğunu ve genellikle SOAP web servisleri ile karşılaştırıldığını görüyorum. programcı, SABUN'u ne zaman kullanacağını ve REST'in ne zaman güzel bir yaklaşım olabileceğini anlamalıdır.

Birkaç yıl önce SOAP'un çok popüler olduğunu (moda?) Ve her iyi CV'de 'SOAP' öğesinin bulunması gerektiğini hatırlıyorum. Ancak pratikte çok nadiren ve çok basit amaçlara ulaşmak için kullanıldı.

Bana öyle geliyor ki, REST bir başka 'modanın son sözü' (ya da tamamen yanlış olabilirim çünkü REST'i pratikte hiç görmedim).

REST'in kullanılması gerektiği ve neden REST olmadan aynısını yapamayacağımız (veya REST olmadan aynısını yapmak için neden daha fazla zaman harcamamız gerektiği) konusunda bana bazı örnekler verebilir misiniz?

UPD : Ne yazık ki ilk yorumlarda aklımı uçuracak somut argümanlar göremiyorum. REST'in harika bir teknoloji olduğunu düşünmemi sağla!

Bunun gibi cevapları görmek isterim:

Başka bir karmaşık HelloWorld uygulaması geliştiriyordum ve çok sayıda / küçük veriyi aktarmamız gerekiyor ve iş arkadaşıma REST çözümü önerdim:

- Oh lanet! Jonny, bu uygulamayı uygulamak için kesinlikle REST kullanmalıyız!
- Evet Billy, REST kullanabiliriz, ama SABUN kullansak iyi olur. Bana güvenin çünkü HelloWorld uygulamaları geliştirme hakkında bir şeyler biliyorum.
- Ama SOAP geçen yüzyıldan kalma eski moda bir teknoloji ve daha iyisini kullanabiliriz.
- Billy, REST ile deney yapmak için 3 gün harcamaya hazır mısın? Bunu SOAP ile 2 saatte yapabiliriz ..
- Evet, SOAP ile aynı güvenliği / performansı / / ölçeklenebilirliği / başka her şeyi elde etmek için daha da fazla zaman harcayacağımızdan eminim. Eminim şu andan itibaren HelloWorld uygulamaları sadece REST ile geliştirilmelidir.

Dağıtılmış bir uygulamada istemci ve sunucu bileşenleri arasındaki bağlantıyı en aza indirmeniz sizin için çok önemliyse REST kullanılmalıdır .

Sunucunuz üzerinde kontrolünüz olmayan birçok farklı istemci tarafından kullanılacaksa bu durum söz konusu olabilir . İstemci yazılımını güncellemenize gerek kalmadan sunucuyu düzenli olarak güncelleyebilmek istiyorsanız da durum söz konusu olabilir .

Sizi temin ederim ki, bu düşük seviyedeki kuplaja ulaşmak kolay değildir . Başarılı olmak için REST'in tüm kısıtlamalarına uymak çok önemlidir. Tamamen vatansız bir bağlantı kurmak zordur. Doğru medya türlerini seçmek ve verilerinizi formatlara sıkıştırmak zordur. Kendi medya türlerinizi oluşturmak daha da zor olabilir.

Zengin sunucu davranışını tek tip HTTP arayüzüne uyarlamak kafa karıştırıcı olabilir ve bazen nispeten basit RPC yaklaşımına kıyasla bilgiçlikçi görünebilir.

Zorluklara rağmen, HTTP protokolünün tutarlı kullanımı nedeniyle bir istemci geliştiricinin kolayca anlayabileceği bir hizmete sahip olmanızın faydaları vardır. Hizmet, hiper ortam nedeniyle kolayca keşfedilebilir olmalı ve istemci , sunucudaki değişikliklere son derece dayanıklı olmalıdır .

Hiper medyanın faydaları ve oturum durumundan kaçınma, yük dengelemeyi basitleştiriyor ve hizmet bölümlemeyi mümkün kılıyor . HTTP kurallarına sıkı uyum, hata ayıklayıcılar ve önbelleğe alma proxy'leri gibi araçların kullanılabilirliğini harika hale getirir.

Güncelleme

Bana öyle geliyor ki, REST bir başka 'modanın son sözü' (ya da tamamen yanlış olabilirim çünkü REST'i pratikte hiç görmedim).

Bence REST moda oldu çünkü SOA tipi projeler yapmaya çalışan insanlar, SOAP yığınını kullanarak vaat edilen faydaları anlamadıklarını anladılar. İnsanlar basit entegrasyon metodolojilerinin bir örneği olarak web'e dönmeye devam ediyor. Ne yazık ki, insanların web'i oluştururken harcanan planlama ve öngörü miktarını hafife aldığını ve web'de meydana gelen şans eseri yeniden kullanıma izin vermek için yapılması gerekenleri fazla basitleştirdiğini düşünüyorum.

Pratikte REST'i hiç görmediğinizi söylüyorsunuz, ancak bir web tarayıcısı kullanıyorsanız bu muhtemelen doğru olamaz. Web tarayıcısı bir REST istemcisidir.

• Birisi bir web sitesinde html değiştirdiğinde neden bir tarayıcı güncellemesi yapmanız gerekmiyor?
• Neden bir web sitesine tamamen yeni bir sayfa grubu ekleyebilirim ve "müşteri" bu yeni sayfalara güncelleme olmadan erişmeye devam edebilir?
• Http://example.org/images/cat adresine gittiğinde dönüş türünün bir jpeg görüntüsü olacağını ve gittiğinizde bunu söylemek için web tarayıcısına neden bir "hizmet açıklama dili" sağlamam gerekmiyor? için http://example.org/description/cat döndürme türü text / html olacak?
• Tarayıcı yayınlandığında var olmayan siteleri ziyaret etmek için neden bir web tarayıcısı kullanabilirim? Müşteri bu sitelerden nasıl haberdar olabilir?

Bunlar mantıksız sorular gibi gelebilir, ancak cevabı biliyorsanız, o zaman REST'in neyle ilgili olduğunu görmeye başlayabilirsiniz. REST'in daha fazla faydası için StackOverflow'a bakın. Bir soruya baktığımda, o sayfaya yer işareti koyabilirim veya url'yi bir arkadaşıma gönderebilirim ve o da aynı bilgileri görebilir. Bu soruyu bulmak için sitede gezinmesi gerekmiyor.

StackOverflow, kimlik doğrulama için çeşitli OpenId hizmetleri, avatar görüntüleri için gravatar.com, analitik bilgiler için google-analytics ve Quantserve kullanır. Bu tür çoklu şirket entegrasyonu, SOAP dünyasının sadece hayalini kurduğu türden bir şeydir . En iyi örneklerden biri, StackOverflow kullanıcı arayüzünü çalıştırmak için kullanılan jQuery kitaplıklarının Google'ın İçerik Dağıtım Ağı'ndan alınmasıdır. SO'nun istemciyi (yani web tarayıcınızı) performansı artırmak için üçüncü taraf bir siteden kod indirmeye yönlendirebilmesi, web istemcisi ile sunucu arasındaki düşük bağlantının kanıtıdır.

Bunlar, işyerinde bir REST mimarisi örnekleridir.

Artık bazı web siteleri / uygulamalar REST kurallarını ihlal ediyor ve ardından tarayıcı beklendiği gibi çalışmıyor.

• Kötü şöhretli geri düğmesi sorunu , sunucu tarafı oturum durumunu kullanmaktan kaynaklanır.
• Sunucu tarafında oturum durumunuz olduğunda yük dengeleme bir sorun haline gelebilir.
• Flash uygulamaları genellikle URL'nin bir temsili özel olarak tanımlamasını engeller.
• Web tarayıcılarını bozan diğer bir sorun, ortam türü standartlarına yetersiz uyumdur. IE6'nın nasıl öldürülmesi gerektiğini her zaman duyuyoruz. Buradaki sorun, standartlara uygun şekilde uyulmaması veya herhangi bir nedenle göz ardı edilmesidir.
• Oturum açma oturumlarının kullanımı birçok güvenlik açığının kaynağıdır.

REST her yerde. Web'in iyi çalışmasını sağlayan kısmıdır. Web gibi ölçeklenebilen dağıtılmış uygulamalar oluşturmak, web gibi değişime dirençli olmak ve web'in yaptığı gibi yeniden kullanımı teşvik etmek istiyorsanız, web tarayıcıları oluştururken uyguladıkları aynı kuralları izleyin.

REST, bildiğim kadarıyla, Roy Fielding'in Mimarlık Tarzları ve Ağ Tabanlı Yazılım Mimarilerinin Tasarımı adlı tezi tarafından başlatıldı , eğer bakmadıysanız okumaya değer.

Tezin en üstünde bir alıntı var:

Hemen hemen herkes doğayla barışık hissediyor: okyanus dalgalarını kıyıya karşı, durgun bir gölün yanında, çimenlik bir alanda, rüzgârla savrulan bir fundalıkta dinlemek. Bir gün, zamansız yolu tekrar öğrendiğimizde, kasabalarımız için de aynı şeyi hissedeceğiz ve bugün okyanus kenarında yürürken ya da uzun çimenlerin arasında uzanırken yaptığımız kadar huzur içinde hissedeceğiz. çayır.

- Christopher Alexander, Zamansız Bina Yolu (1979)

Ve bu gerçekten orada özetliyor. REST birçok yönden daha zariftir.

SOAP, HTTP'nin üstünde bir protokoldür, bu nedenle SOAP'ta yeni kurallar oluşturmak için birçok HTTP kuralını atlar ve birkaç yönden HTTP ile gereksizdir. Bununla birlikte, HTTP, bilgileri HTTP yoluyla geri almak, aramak, yazmak ve silmek için fazlasıyla yeterlidir ve REST'in çoğu da budur. REST, üstüne değil HTTP ile oluşturulduğundan, bununla entegre olmak isteyen yazılımın (web tarayıcısı gibi) bunu yapmak için SOAP'u anlamasına gerek olmadığı anlamına gelir, sadece HTTP, en önemlisi bu noktada kullanımda olan protokol ile yaygın olarak anlaşılmış ve entegre edilmiştir.

Gönderen burada :

REST avantajları:

• Hafif - çok fazla xml işaretlemesi yok
• İnsan Tarafından Okunabilir Sonuçlar
• Oluşturması kolay - alet takımı gerekmez

Ayrıca kontrol Bu Çıkış:

Adil olmak gerekirse, REST her Web hizmeti için en iyi çözüm değildir. Güvenli olması gereken veriler, URI'lerde parametre olarak gönderilmemelidir. Ve ayrıntılı satın alma siparişlerinde olduğu gibi büyük miktarda veri, hızla hantal hale gelebilir ve hatta bir URI içinde sınırların dışına çıkabilir. Bu durumlarda, SABUN gerçekten sağlam bir çözümdür. Ancak önce REST'i denemek ve sadece gerektiğinde SABUN'a başvurmak önemlidir. Bu, uygulama geliştirmeyi basit ve erişilebilir tutmaya yardımcı olur.

Bunu yeni başlayan biri olarak anlamak için çok zaman harcadığımı rahatlıkla söyleyebilirim ama bu, REST ile sıfırdan başlamak için en iyi bağlantı! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Sadece seni içeri çekmek için

"Geleneksel web hizmetinin" ne olduğunu düşünün. Açık "yöntemler" ile bir arayüzdür. İstemciler yöntemlerin adını, girişini ve çıkışını bilir ve dolayısıyla onları çağırabilir.

Şimdi "yöntemleri" açığa çıkarmayan bir arayüz hayal edin. Bunun yerine, "nesneleri" ortaya çıkarır. Dolayısıyla, bir müşteri bu arayüzü gördüğünde, tek gördüğü bir veya daha fazla "nesne" dir. "Bir nesne" nin girdi ve çıktısı yoktur - çünkü "hiçbir şey yapmaz". Bu bir isim, fiil değil. Bu bir "şey", "eylem" değil.

Örneğin, bir şehir sağladığınız takdirde mevcut hava koşullarını sağlayan geleneksel bir web hizmeti düşünün. Muhtemelen giriş olarak bir şehri alan ve çıktı olarak hava durumu verilerini sağlayan GetWeatherInfo () gibi bir web yöntemine sahiptir. Bir müşterinin bu web hizmetini nasıl kullanacağını anlamak şu ana kadar sizin için kolaydır.

Şimdi, yukarıdaki web hizmetinin yerine, şehirleri nesneler olarak ortaya çıkaran yeni bir hizmetin olduğunu hayal edin. Dolayısıyla, GetWeatherInfo () yerine bir müşteri olarak baktığınızda New York, Dallas, Los Angeles, Londra vb. Görürsünüz. Ve bu şehirlerin kendilerinden sarkan uygulamaya özgü yöntemleri yok - görünüşe göre inert gazlar gibiler - kendileri tepki vermiyorlar.

Düşünüyor olmalısın - peki, bu bir müşteri olarak Dallas'ın havasını görmenize nasıl yardımcı olur? Buna birkaç dakika içinde ulaşacağız.

Bir web hizmetinden aldığınız tek şey bir "nesneler kümesi" ise, tabii ki "onlara göre hareket etmenin" bir yolunu bulmanız gerekir. Nesnelerin kendilerinin çağırabileceğiniz hiçbir yöntemi yoktur, bu nedenle bu nesnelere uygulayabileceğiniz bir dizi eylem gerekir. Başka bir deyişle, "isme bir fiil uygulamanız" gerekir. Bir nesne görürseniz, diyelim ki "isim" olan bir elma, ona eat gibi "bir fiil" uygulayabilirsiniz. Ancak tüm fiiller tüm isimlere uygulanamaz. Mesela araba sürebilirsin ama televizyon kullanamazsın.

Bu nedenle, bir web hizmeti yalnızca nesneleri açığa çıkarırsa ve sizden istenirse - şimdi "tüm istemcilerin gördükleri tüm nesnelere uygulayabileceği" birkaç standart eylem veya fiil tasarlayalım, ...

İşte bazı fikirler:

• REST, hizmetinizi tek tip bir arayüz kullanacak şekilde kısıtlar. Hizmetinizin çalışabileceği tüm olası yollar hakkında hayal kurarak (veya tartışarak) zaman kaybetmek zorunda değilsiniz - sisteminizdeki kaynakları belirleyerek çalışmaya başlayabilirsiniz. Kendi başına büyük bir iş olduğu ortaya çıkıyor, ancak neyse ki sorunlar çok daha iyi tanımlanma eğiliminde.
• Kaynaklar, dernekleri ve temsilleri elinizde olduğunda, hizmetinizi uygulamak için gerçekten çok az şey var çünkü sizin için birçok karar verildi.
• Sisteminiz diğer RESTful sistemlerine çok benzeyecek; Takım arkadaşları, ortaklar ve müşteriler için öğrenme eğrileri azaltılacaktır.
• Tasarım sorunlarını diğer geliştiricilerle ve hatta teknik olarak daha az düşünenlerle (müşteriler gibi) tartışmak için ortak bir kelime bilginiz olacak.
• Darrel'in dediği gibi, hipermetin temelli bir tasarım kullandığınız için, hizmetiniz bağlantı kapsamını tek bir şeye, medya türlerine daraltır. Bu, bir geliştirici olarak size yardımcı olur çünkü sisteminizdeki değişiklikler dar bir iletişim bandında bulunur. Bu, müşterilerinizin daha az sayıda değişikliğin kodlarını kırmasına yardımcı olur.
• REST'i uygularken karşılaşabileceğiniz hemen hemen her sorun , yeni bir kaynak ortaya çıkararak veya kaynak modelinizi yeniden düşünerek çözülebilir . Bu odak noktası, IMO, büyük bir verimlilik artışıdır.

Sonuç olarak, REST, en çok zaman alan ve tartışmalı tasarım ve uygulama kararlarının çoğunu ekibinizin iş akışından kaldırır. Bu dikkatinizi kaydırır uygulamak için hizmet tasarımı onu. Ve bunu HTTP protokolüne gobbledygook yüklemeden yapar.

REST ile ilgili "profesyonel" yanıtların çoğu, görev için uygun araçlar sağlayan bir ortam kullanan bir SOAP web hizmeti veya istemcisi geliştirmemiş kişilerden geliyor gibi görünüyor. Visual Studio .NET ve IBM'in Rational Web Developer'ı kullanarak hiç karşılaşmadığım sorunlardan şikayet ediyorlar. Bir betik dilinde veya çok az araç desteği olan veya hiç olmayan başka bir dilde web hizmetleri veya istemciler geliştirmeniz gerekiyorsa, bunların geçerli şikayetler olduğunu varsayıyorum.

Ayrıca, "profesyonel" noktaların birçoğunun kulağa doğru olabilecek şeyler gibi geldiğini kabul etmeliyim - ancak bunların değerlerini gösteren bir örnek hiç görmedim. Özellikle, birisi REST web hizmetinin iyi bir örneğine bağlantı içeren bir yorum yayınlarsa çok memnun olurum. Bu, muhtemelen bir hiyerarşide birden çok düzeyde kaynak kullanan ve ortam türlerini uygun şekilde kullanan bir kaynak olmalıdır. Belki iyi bir örneğe bakarsam anlarım, bu durumda buraya geri dönüp itiraf edeceğim.

Halihazırda bulunduğum yerde REST hizmetlerini kullanmamızın nedeni verilen yanıtlara biraz yavan bir yorum eklemek, bir iş ortağına bir URL verebileceğinizi ve karşılığında güzel bir şekilde düzenlenmiş bir XML levhası alacağını bilirseniz. .Net xx, PHP, Python, Java, Ruby veya tanrı bilir - neyin baş ağrısını ciddi şekilde azalttığı önemli değil.

Bu aynı zamanda, teknik olmayan uçta satış personelimizin, çok yönlü API'miz hakkında tam bir kukla gibi görünmekten korkmadan insanlara övünebileceği anlamına gelir.

Teknik avantajlar dışında, teknik bilgisi olmayan birinin açıklaması, göstermesi ve kendinden emin olması kolay olan her şey iyi bir şeydir. SOAP, teknisyenler için ne kadar havalı olsa da, teknik olmayanlar tarafından çok daha az ulaşılabilir ve bu nedenle "satmak" o kadar kolay değildir.

Teknisyen olmayanların kafalarını çevirebilecekleri şeylerin takılma eğiliminde olduğunu fark etme eğilimindeyim. Bu yüzden, modanın kaprislerine SABUN kadar duyarlı olmasının bir teknik olarak REST'ten şüpheliyim.

Ancak bir REST hizmetine kilitlenmesi gereken hiçbir şey koymama ile ilgili her şey, yalnızca teknolojinin teknik olarak çok düşünmeyen insanlar tarafından çok kolay anlaşılması nedeniyle iki kat doğrudur.

REST, ağa bağlı uygulamaları tasarlamak için bir mimari stildir. Buradaki fikir, makineler arasında bağlantı kurmak için CORBA, RPC veya SOAP gibi karmaşık mekanizmalar kullanmak yerine, makineler arasında arama yapmak için basit HTTP'nin kullanılmasıdır.

Birçok yönden, HTTP'ye dayalı World Wide Web'in kendisi REST tabanlı bir mimari olarak görülebilir. RESTful uygulamalar, verileri göndermek (oluşturmak ve / veya güncellemek), verileri okumak (örneğin, sorgular yapmak) ve verileri silmek için HTTP isteklerini kullanır. Bu nedenle REST, dört CRUD (Oluşturma / Okuma / Güncelleme / Silme) işlemlerinin tümü için HTTP kullanır.

REST, RPC (Uzaktan Prosedür Çağrıları) ve Web Servisleri (SOAP, WSDL ve diğerleri) gibi mekanizmalara hafif bir alternatiftir. Daha sonra REST'in ne kadar basit olduğunu göreceğiz.

Basit olmasına rağmen, REST tam özelliklidir; RESTful mimarisi ile yapılamayacak temelde Web Servislerinde yapabileceğiniz hiçbir şey yoktur. REST bir "standart" değildir. Örneğin, REST için hiçbir zaman bir W3C önerisi olmayacaktır. Ve REST programlama çerçeveleri varken, REST ile çalışmak o kadar basittir ki, Perl, Java veya C # gibi dillerdeki standart kitaplık özellikleriyle genellikle "kendi başınıza dönebilirsiniz".