Birisi REST nedir ve açık İngilizce'de SOAP nedir açıklayabilir mi? Web Servisleri nasıl çalışır?

SOAP ve REST hakkında basit açıklama

SOAP - "Basit Nesne Erişim Protokolü"

SOAP, mesajları veya az miktarda bilgiyi İnternet üzerinden aktarma yöntemidir. SOAP mesajları XML olarak biçimlendirilir ve genellikle HTTP (köprü metni aktarım protokolü) kullanılarak gönderilir.

Dinlenme - Temsil durumu aktarımı

Dinlenme, istemci ve sunucu arasında veri gönderip almanın basit bir yoludur ve çok fazla standart tanımlanmamıştır. JSON, XML veya düz metin olarak veri gönderebilir ve alabilirsiniz. SOAP ile karşılaştırıldığında hafif ağırlıklı.

Her iki yöntem de büyük oyuncuların çoğu tarafından kullanılır. Bu bir tercih meselesi. Benim tercihim REST'tir çünkü kullanımı ve anlaşılması daha kolaydır.

Basit Nesne Erişim Protokolü (SOAP):

• SOAP, HTTP veya bazen TCP / IP üzerine bir XML protokolü oluşturur.
• SOAP işlevleri ve veri türlerini açıklar.
• SOAP, XML-RPC'nin ardılıdır ve çok benzerdir, ancak iletişim kurmanın standart bir yolunu tanımlar.
• Birkaç programlama dili SOAP için yerel desteğe sahiptir, tipik olarak bir web hizmeti URL'si beslersiniz ve web hizmeti işlevlerini belirli bir koda ihtiyaç duymadan arayabilirsiniz.
• Gönderilen ikili veriler önce base64 gibi bir formata kodlanmalıdır.
• Bununla ilgili birkaç protokol ve teknolojiye sahiptir: WSDL, XSD'ler, SOAP, WS-Adresleme

Temsil durumu aktarımı (REST):

• REST'in HTTP üzerinden olması gerekmez, ancak aşağıdaki noktaların çoğunda bir HTTP önyargısı olacaktır.
• REST çok hafif, bir dakika bekleyin diyor, SOAP'ın yarattığı bu karmaşıklığın hepsine ihtiyacımız yok.
• Genellikle her şeyi açıklayan büyük bir XML biçimi yerine normal HTTP yöntemlerini kullanır. Örneğin HTTP GET kullandığınız bir kaynak elde etmek için, sunucuya bir kaynak koymak için HTTP PUT kullandığınız bir kaynak. Sunucudaki bir kaynağı silmek için HTTP DELETE kullanırsınız.
• REST, sunucudaki kaynakları güncellemek için HTTP GET, POST ve PUT yöntemlerini kullanması açısından çok basittir.
• REST tipik olarak en iyi Kaynak Odaklı Mimari (ROA) ile kullanılır. Bu düşünme tarzında her şey bir kaynaktır ve bu kaynaklar üzerinde çalışacaksınız.
• Programlama dilinizde bir HTTP kütüphanesi olduğu ve çoğunda olduğu sürece, REST HTTP protokolünü çok kolay bir şekilde tüketebilirsiniz.
• İkili veriler veya ikili kaynaklar istekleri üzerine kolayca sağlanabilir.

Google'da REST vs SOAP ile ilgili sonsuz tartışmalar var .

Benim favorim bu . Güncelleme 27 Kasım 2013: Paul Prescod'un sitesi çevrimdışı görünüyor ve bu makale artık mevcut değil, yine de kopyalar Wayback Machine'de veya CiteSeerX'te PDF olarak bulunabilir .

DİNLENME

REST'in ana fikrinin son derece basit olduğunu anlıyorum. Web tarayıcılarını yıllardır kullandık ve web sitelerinin ne kadar kolay, esnek, performans sergilediğini gördük. HTML siteleri, kullanıcı etkileşiminin birincil aracı olarak köprüler ve formlar kullanır. Ana hedefleri, müşterilerimize, sadece mevcut durumda kullanabileceğimiz bağlantıları bilmemize izin vermektir . Ve REST basitçe 'neden uygulamamız aracılığıyla insan istemciler yerine bilgisayarı sürmek için aynı ilkeleri kullanmıyorsunuz?' Bunu WWW altyapısının gücü ile birleştirdiğinizde, harika dağıtılmış uygulamalar oluşturmak için bir katil araç elde edersiniz.

Başka bir olası açıklama, matematiksel düşünen insanlar içindir. Her uygulama temel olarak bir durum makinesidir ve iş mantığı eylemleri durum geçişleri olur. REST fikri, bir kaynağa yapılan bazı talepler üzerindeki her geçişi eşleştirmek ve istemcilere geçerli durumda kullanılabilen geçişleri temsil eden bağlantılar sağlamaktır. Böylece devlet makinesini temsiller ve bağlantılar yoluyla modeller. Bu yüzden REPresentation State Transfer denir.

Tüm cevapların mesaj biçimine veya HTTP fiillerinin kullanımına odaklanmış gibi görünmesi şaşırtıcıdır. Aslında, mesaj formatı hiç önemli değil, REST, servis geliştiricisinin dokümantasyonu şartıyla herhangi birini kullanabilir. HTTP fiilleri bir hizmeti sadece bir CRUD servisi yapar, ancak henüz RESTful yapmaz. Bir hizmeti gerçekten REST hizmetine dönüştüren şey, verilerle birlikte sunucu yanıtlarına katıştırılmış köprülerdir (hipermedia denetimleri olarak da bilinir) ve miktarları, herhangi bir istemcinin bu bağlantılardan sonraki eylemi seçmesi için yeterli olmalıdır.

Ne yazık ki, Roy Fielding'in tezi hariç, REST hakkında Web'de doğru bilgi bulmak oldukça zor . (REST'i türeyen kişi odur). SOAP'tan REST'e nasıl geçileceği konusunda kapsamlı bir adım adım eğitim veren 'Uygulamada REST' kitabını öneriyorum .

SABUN

Bu, RPC (uzaktan yordam çağrısı) mimari stilinin olası biçimlerinden biridir. Temelde, bu, istemcilere yerel yöntemleri çağırıyormuş gibi hizmet sınırları (ağ, süreçler, vb.) Aracılığıyla sunucu yöntemlerini çağırma olanağı sağlayan bir teknolojidir. Tabii ki, aslında hız, güvenilirlik ve benzeri yerel yöntemleri çağırmaktan farklıdır, ancak fikir bu kadar basittir.

karşılaştırıldığında

Aktarım protokolleri, mesaj formatları, xsd, wsdl, vb. Gibi detaylar RPC ile herhangi bir RPC formunu karşılaştırırken önemli değildir. Temel fark, bir RPC hizmetinin, sadece bildiği anlambilim ile RPC API'sindeki kendi uygulama protokolünü tasarlayarak bisikleti yeniden icat etmesidir. Bu nedenle, tüm istemciler hizmeti kullanmadan önce bu protokolü anlamalıdır ve tüm isteklerin tescilli semantiği nedeniyle önbellek gibi genel bir altyapı oluşturulamaz. Ayrıca, RPC API'leri mevcut durumda hangi eylemlere izin verildiğini önermez, bu ek belgelerden türetilmelidir. Öte yandan REST, çeşitli istemcilerin API anlambilimi hakkında biraz bilgi sahibi olmasını ve her durumda mevcut seçenekleri vurgulamak için hiper ortam denetimlerini (bağlantıları) sağlamak için tek tip arabirimler kullanmayı gerektirir. Böylece,

Bir şekilde, SOAP (diğer RPC'ler gibi), bağlantı ortamını yalnızca mesaj iletebilen bir kara kutu olarak ele alan bir servis sınırı boyunca tünel açma girişimidir. REST, Web'in büyük bir dağıtılmış bilgi sistemi olduğunu kabul etmek, dünyayı olduğu gibi kabul etmek ve ona karşı savaşmak yerine ona hakim olmayı öğrenmek için bir karardır.

SOAP, hem sunucuyu hem de istemcileri kontrol ettiğinizde ve etkileşimler çok karmaşık olmadığında dahili ağ API'leri için harika görünüyor. Geliştiricilerin kullanması daha doğal. Bununla birlikte, birçok bağımsız taraf tarafından kullanılan, karmaşık ve büyük bir genel API için, REST daha iyi uymalıdır. Ancak bu son karşılaştırma çok bulanık.

Güncelleme

Deneyimlerim beklenmedik bir şekilde REST gelişiminin SOAP'tan daha zor olduğunu gösterdi. En azından .NET için. ASP.NET Web API gibi harika çerçeveler olsa da, istemci tarafı proxy'yi otomatik olarak oluşturacak hiçbir araç yoktur. 'Web Hizmeti Referansı Ekle' veya 'WCF Servis Referansı Ekle' gibi bir şey yok. Tüm serileştirme ve servis sorgulama kodlarını elle yazmak gerekir. Ve dostum, bu çok sayıda kaynak kodu. REST geliştirmesinin WSDL ve her geliştirme platformu için takım uygulamasına benzer bir şeye ihtiyacı olduğunu düşünüyorum. Aslında, iyi bir zemin var gibi görünüyor: WADL veya WSDL 2.0 , ancak standartların hiçbiri iyi desteklenmiyor gibi görünüyor.

Güncelleme (Ocak 2016)

Şimdi REST API tanımı için çok çeşitli araçlar olduğu ortaya çıkıyor. Kişisel tercihim şu anda RAML .

Web Hizmetleri nasıl çalışır?

Bu çok geniş bir soru, çünkü belirli web hizmetinde kullanılan mimariye ve teknolojiye bağlı. Ancak genel olarak, bir web hizmeti Web'deki istemcilerden gelen istekleri kabul edebilen ve yanıtları döndürebilen bir uygulamadır. Web'e açıktır, bu nedenle bir web hizmetidir ve genellikle 7/24 kullanılabilir, bu yüzden bir hizmettir . Tabii ki, müşterileri için bazı problemleri çözer (aksi takdirde birileri neden bir web hizmeti kullanırdı).

Bu şimdiye kadar bulabileceğiniz en basit açıklama.

Bu makale, bir kocayı karısına anlatıyor, burada kocası karısına REST hakkında saf layman terimleriyle açıklıyor. Okunmalı!

nasıl-i-açıkladı-karıma kalan (orijinal bağlantı)
nasıl-i-açıkladı-karıma kalan (2013-07-19 çalışma bağlantı)

SOAP - Basit Nesne Erişim Protokolü bir protokoldür !

DİNLENME - rest is an mimari tarzı !

SOAP genellikle HTTP üzerinden ileti aktarmak için kullanılan bir XML protokolüdür

RESTve SOAPvardır tartışmasız değil birbirini dışlayan. Bir RESTful mimari kullanabilir HTTPveya SOAPbaşka bir iletişim protokolü veya. RESTweb için optimize edilmiştir ve bu nedenle HTTPmükemmel bir seçimdir. HTTPayrıca sadece Roy Fielding'in tartışılmıştır protokol.

Her ne kadar REST ve SOAP açıkça çok farklı olsa da, soru RESTve HTTPbunların sıklıkla birlikte kullanıldığı gerçeğini aydınlatır . Bu öncelikle HTTP'nin basitliğinden ve RESTful ilkelerine çok doğal eşlenmesinden kaynaklanmaktadır.

Temel REST İlkeleri

İstemci-Sunucu İletişimi

İstemci-sunucu mimarilerinin endişeleri birbirinden çok farklıdır. RESTful tarzında oluşturulan tüm uygulamalar, yazıcıda istemci-sunucu olmalıdır.

vatansız

Sunucuya yapılan her istemci isteği, durumunun tam olarak temsil edilmesini gerektirir. Sunucu, herhangi bir sunucu bağlamı veya sunucu oturumu durumu kullanmadan istemci isteğini tam olarak anlayabilmelidir. Tüm durumun istemcide tutulması gerektiği sonucuna varılır. Vatansız temsilini daha sonra daha ayrıntılı olarak ele alacağız.

cacheable

Önbellek kısıtlamaları kullanılabilir, böylece yanıt verilerinin önbelleğe alınabilir veya erişilemez olarak işaretlenmesi sağlanır. Önbelleğe alınabilir olarak işaretlenen tüm veriler, aynı sonraki isteğe yanıt olarak yeniden kullanılabilir.

Düzgün Arayüz

Tüm bileşenler tek bir tek tip arabirim üzerinden etkileşime girmelidir. Tüm bileşen etkileşimi bu arabirim üzerinden gerçekleştiğinden, farklı hizmetlerle etkileşim çok basittir. Arayüz aynı! Bu aynı zamanda uygulama değişikliklerinin tek başına yapılabileceği anlamına gelir. Bu tür değişiklikler, üniform arayüz her zaman değişmediği için temel bileşen etkileşimini etkilemez. Bir dezavantajı, arayüze sıkışmış olmanızdır. Arabirim değiştirilerek belirli bir hizmete bir optimizasyon sağlanabilirse, REST bunu yasakladığı için şansınız kalmaz. Bununla birlikte, parlak tarafta, REST web için optimize edilmiştir, bu nedenle HTTP üzerinden REST'in inanılmaz popülaritesi!

Yukarıdaki kavramlar REST'in tanımlayıcı özelliklerini temsil eder ve REST mimarisini web hizmetleri gibi diğer mimarilerden farklı kılar. Bir REST hizmetinin bir web hizmeti olduğunu, ancak bir web hizmetinin mutlaka bir REST hizmeti olmadığını belirtmek yararlıdır.

Bu blog Bkz yazısı üzerine DİNLENME Tasarım Esasları hakkında daha fazla ayrıntı için DİNLENME ve yukarıda belirtilen kurşunlar.

Brian R. Bondy'nin cevabını seviyorum. Sadece Wikipedia'nın REST'in net bir açıklamasını sağladığını eklemek istedim . Makale onu SOAP'tan ayırıyor.

REST, mümkün olduğunca basit bir şekilde yapılan bir devlet bilgi alışverişidir.

SOAP, XML kullanan bir mesaj protokolüdür.

Birçok insanın SOAP'tan REST'e taşınmasının ana nedenlerinden biri, SOAP tabanlı web hizmetleriyle ilişkili WS- * (WS splat olarak adlandırılır) standartlarının son derece karmaşık olmasıdır. Spesifikasyonların bir listesi için wikipedia'ya bakınız . Bu özelliklerin her biri çok karmaşıktır.

EDIT: bazı nedenlerden dolayı bağlantılar düzgün görüntülenmiyor. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Hem SOAP web servisleri hem de REST web servisleri HTTP protokolünü ve diğer protokolleri de kullanabilir (sadece SOAP'tan bahsetmek temel REST protokolü olabilir). Sadece HTTP protokolü ile ilgili SOAP ve REST hakkında konuşacağım, çünkü bu en sık kullanılanıdır.

SABUN

SOAP ("basit" nesne erişim protokolü) bir protokoldür (ve bir W3C standardı ). SOAP mesajlarının nasıl oluşturulacağını, gönderileceğini ve işleneceğini tanımlar.

• SOAP mesajları belirli bir yapıya sahip XML belgeleridir: üstbilgi ve gövde bölümünü içeren bir zarf içerirler. Gövde, göndermek istediğimiz gerçek verileri XML biçiminde içerir. Orada iki kodlama stilleri , ama biz genellikle edebi tercih eden uygulama veya SABUN sürücü verilerinin XML seri ve unserialization yaptığı hangi araçları.

• SOAP iletileri, SOAP + XML MIME alt türüyle HTTP iletileri olarak seyahat eder. Bu HTTP iletileri çok parçalı olabilir, bu nedenle isteğe bağlı olarak SOAP iletilerine dosya ekleyebiliriz.

• Açıkçası bir istemci-sunucu mimarisi kullanıyoruz, böylece SOAP istemcileri SOAP web sunucularına istek gönderiyor ve hizmetler istemcilere yanıtları geri gönderiyor. Web hizmetlerinin çoğu, hizmeti tanımlamak için bir WSDL dosyası kullanır. WSDL dosyası, göndermek istediğimiz verilerin XML Şemasını (bundan sonra XSD) ve web hizmetinin HTTP protokolüne nasıl bağlanacağını tanımlayan WSDL bağını içerir. Orada iki bağlanma stilleri: RPC ve belge. RPC stili bağlandığında SOAP gövdesi, bir işlem çağrısının parametrelerle (HTTP istekleri) veya dönüş değerleriyle (HTTP yanıtı) temsilini içerir. Parametreler ve dönüş değerleri XSD'ye göre doğrulanır. Belge stili bağlandığında SOAP gövdesi, XSD'ye göre doğrulanmış bir XML belgesi içerir. Belge bağlama stilinin olay tabanlı sistemlere daha uygun olduğunu düşünüyorum, ancak bu bağlama stilini hiç kullanmadım. RPC bağlama stili daha yaygındır, bu nedenle çoğu kişi SOAP'ı dağıtılmış uygulamalar tarafından XML / RPC amaçları için kullanır. Web servisleri genellikle bir UDDI sunucusu sorarak birbirlerini bulurlar . UDDI sunucuları, web hizmetlerinin konumunu depolayan kayıtlardır.

SABUN RPC

- Bence - en yaygın SOAP webservisi RPC bağlama stili ve değişmez kodlama stili kullanır ve aşağıdaki özelliklere sahiptir:

• URL'leri işlemlerle eşler.
• SOAP + XML MIME alt türüyle mesaj gönderir.
• Bir sunucu tarafı oturum deposu olabilir, bununla ilgili herhangi bir kısıtlama yoktur.
• SOAP istemci sürücüleri, RPC işlemlerini yöntemlere dönüştürmek için hizmetin WSDL dosyasını kullanır. İstemci tarafı uygulaması, bu yöntemleri çağırarak SOAP web hizmetiyle iletişim kurar. Böylece SOAP istemcilerinin çoğu arayüz değişikliklerine (sonuçta ortaya çıkan yöntem adları ve / veya parametre değişiklikleri) zarar verir.
• RDF kullanarak arabirim değişiklikleriyle kırılmayan ve semantik tarafından işlemleri bulamayan SOAP istemcileri yazmak mümkündür, ancak semantik web hizmeti çok nadirdir ve mutlaka kopmayan bir istemciye sahip değildir (sanırım).

DİNLENME

REST (temsili durum transferi) Roy Fielding'in tezinde açıklanan bir mimari stilidir . SOAP gibi protokollerle ilgili değildir. Hiçbir kısıtlaması olmayan boş bir mimari stiliyle başlar ve REST mimarisinin kısıtlamalarını tek tek tanımlar. İnsanlar RESTful terimini tüm REST kısıtlamalarını yerine getiren web hizmetleri için kullanır, ancak Roy Fielding'e göre REST seviyeleri diye bir şey yoktur . Bir web hizmeti her bir REST kısıtlamasıyla karşılaşmadığında, bir REST web hizmeti değildir.

REST kısıtlamaları

• İstemci - sunucu mimarisi - Bence bu bölüm herkese tanıdık geliyor. REST istemcileri REST web hizmetleriyle iletişim kurar, web hizmetleri ortak veriyi (bundan sonra kaynak durumu) korur ve bunu müşterilere sunar.
• Vatansız - Kısaltmanın "durum aktarımı" bölümü: REST. İstemciler istemci durumunu (oturum / uygulama durumu) korur, bu nedenle hizmetlerin oturum depolaması olmamalıdır. İstemciler, kaynak durumunun ilgili bölümüyle (onlar tarafından korunan) yanıt veren hizmetlere her istekle müşteri durumunun ilgili kısmını aktarır. Dolayısıyla isteklerin bağlamı yoktur, bunları işlemek için her zaman gerekli bilgileri içerirler. Örneğin, HTTP temel kimlik doğrulaması ile kullanıcı adı ve parola istemci tarafından saklanır ve bunları her istekte gönderir, bu nedenle kimlik doğrulama her istekte gerçekleşir. Bu, kimlik doğrulamanın yalnızca girişle gerçekleştiği normal web uygulamalarından çok farklıdır. Bellek içi (javascript), çerezler, localStorage ve benzeri herhangi bir istemci tarafı veri depolama mekanizmasını kullanabiliriz ... eğer istersek müşteri devletinin bazı kısımlarını devam ettirmek. Vatansızlık kısıtlamasının nedeni, sunucunun her bir istemcinin oturumunu sürdürmesi gerekmediğinde (çok fazla yük (milyonlarca kullanıcı) bile) iyi ölçeklendirilmesidir.
• Önbellek - Yanıt, istemci tarafından önbelleğe alınabileceği hakkında bilgi içermelidir. Bu ölçeklenebilirliği daha da geliştirir.

• Düzgün arayüz

  • Kaynakların tanımlanması - REST kaynağı RDF kaynağı ile aynıdır . Fielding'e göre bir şeyi adlandırabiliyorsanız, bu bir kaynak olabilir, örneğin: "mevcut yerel hava durumu" bir kaynak olabilir veya "cep telefonunuz" bir kaynak olabilir veya "belirli bir web belgesi" olabilir kaynak. Bir kaynağı tanımlamak için kaynak tanımlayıcılarını kullanabilirsiniz: URL'ler ve URN'ler (örneğin , kitaplara göre ISBN numarası ). Tek bir tanımlayıcı yalnızca belirli bir kaynağa ait olmalıdır, ancak tek bir kaynağın, örneğin URL'lerle sayfalandırma yoluyla sık sık kullandığımız birçok tanımlayıcı olabilir https://example.com/api/v1/users?offset=50&count=25. URL'lerin bazı özellikleri var, örneğin aynı yollara sahip ancak farklı sorgular olan URL'ler aynı değildir veya yol kısmı URL'nin hiyerarşik verilerini içermeli ve sorgu kısmı hiyerarşik olmayan verileri içermelidir. Bunlar, REST ile URL oluşturma yöntemlerinin temelleridir. Btw. URL yapısı yalnızca hizmet geliştiriciler için önemlidir, gerçek bir REST istemcisi bununla ilgilenmez. Sıkça sorulan bir diğer soru, kolay olan API sürümüdür, çünkü Fielding'e göre kaynağa göre tek sabit şey anlambilimdir. Anlambilim değişirse, yeni bir sürüm numarası ekleyebilirsiniz. Klasik 3 numara sürüm oluşturmayı kullanabilir ve URL'lere yalnızca büyük sayıyı ekleyebilirsiniz (https://example.com/api/v1/). Dolayısıyla geriye dönük uyumlu değişikliklerle hiçbir şey olmaz, geriye dönük uyumlu olmayan değişiklikler sayesinde yeni bir API köküne sahip geriye dönük uyumlu olmayan bir semantiğiniz olur https://example.com/api/v2/. Eski istemciler kırılmaz, çünkü https://example.com/api/v1/eski semantikle birlikte kullanabilirler .
  • Temsiller yoluyla kaynakların işlenmesi - Kaynakların (kaynak durumu) ilgili verilerini, HTTP yöntemiyle ve kaynak tanımlayıcıyla birlikte kaynakların (REST) ​​hizmetine göndererek değiştirebilirsiniz. Örneğin, bir kullanıcıyı evlilikten sonra yeniden adlandırmak istiyorsanız , istenen kaynak durumunun JSON temsilidir, başka bir deyişle yeni ad olan bir PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}istek gönderebilirsiniz {name: "Mrs Smith"}. Bu durumun tersi olur, hizmet durumlarını değiştirmek için istemcilere kaynakların temsillerini gönderir. Örneğin, yeni adı okumak istiyorsak, bir GET https://example.com/api/v1/users/1?fields="name"geri alma isteği gönderebiliriz .200 ok, {name: "Mrs Smith"}tepki. Bu temsili müşteri durumunu değiştirmek için kullanabiliriz, örneğin "Sayfamıza hoş geldiniz Bayan Smith!" İleti. Bir kaynağın, kaynak tanımlayıcısına (URL) veya acceptistekle birlikte gönderdiğimiz başlığa bağlı olarak birçok temsili olabilir . Örneğin image/jpeg, istenirse Bayan Smith (muhtemelen çıplak değil) görüntüsünü gönderebiliriz .
  • Kendini tanımlayan mesajlar - Mesajların nasıl işleneceği hakkında bilgi içermelidir. Örneğin, URI ve HTTP yöntemi, içerik türü üstbilgisi, önbellek üstbilgileri, verinin anlamını açıklayan RDF, vb ... Standart yöntemler kullanmak önemlidir. HTTP yöntemlerinin özelliklerini bilmek önemlidir . Verilen URL tarafından belirlenen kaynak silmek için sunucu isteyen SİL araçlar, vb ... HTTP üzerinde istek URL tarafından belirlenen bilgi alınırken örnek GET aracı için durum kodları bir var şartname yanı örnek 200 araç başarı için, 201 aracı yeni bir kaynak yaratıldı, 404, istenen kaynağın sunucuda bulunmadığı anlamına gelir, vb ... Mevcut standartları kullanmak REST'in önemli bir parçasıdır.

  • Uygulama durumunun motoru olarak hiper ortam (bundan sonra HATEOAS olarak anılacaktır) - Hiper Ortam, köprüler içerebilen bir medya türüdür. Web'de, URL'leri adres çubuğuna yazmak yerine, bir hedefe ulaşmak için hiper ortam formatıyla (genellikle HTML) açıklanan bağlantıları izliyoruz. REST aynı konsepti takip eder, servis tarafından gönderilen temsiller köprüler içerebilir. Bu köprüleri servise istek göndermek için kullanırız. Yanıtla, yeni istemci durumunu oluşturmak için kullanabileceğimiz veriler (ve muhtemelen daha fazla bağlantı) alıyoruz ve bu yüzden ... Bu yüzden hiper ortam uygulama durumunun (istemci durumu) motorudur. Muhtemelen müşteriler köprüleri nasıl tanır ve takip eder? İnsanlar tarafından oldukça basit, bağlantının başlığını okuyoruz, belki giriş alanlarını dolduruyoruz ve bundan sonra sadece tek bir tıklama.Hydra ile JSON-LD ) veya hiper medyaya özgü çözümlerle (örneğin IANA bağlantı ilişkileri ve HAL + JSON tarafından satıcıya özel MIME türleri ). Makine tarafından okunabilen birçok XML ve JSON hiper ortam formatı vardır , bunların sadece kısa bir listesi:

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Siren
    • Koleksiyon + JSON

    Bazen seçmek zor ...

• Katmanlı sistem - İstemciler ve hizmetler arasında birden çok katman kullanabiliriz. Hiçbiri bu ek katmanların tümünü, hemen yanındaki katmanı bilmemelidir. Bu katmanlar, önbellek ve yük dengelemesi uygulayarak ölçeklenebilirliği artırabilir veya güvenlik ilkelerini uygulayabilir.
• İstek üzerine kod - İstemcinin işlevselliğini genişleten kodu, örneğin javascript kodunu bir tarayıcıya geri gönderebiliriz. Bu, REST'in tek isteğe bağlı kısıtlamasıdır.

REST web hizmeti - SOAP RPC web hizmeti farklılıkları

Bu yüzden bir REST web servisi bir SOAP web servisinden çok farklıdır (RPC bağlama stili ve değişmez kodlama stili ile)

• Tek tip bir arayüz tanımlar (bir protokol yerine).
• URL'leri kaynaklarla eşleştirir (işlemleri değil).
• Herhangi bir MIME türüyle ileti gönderir (yalnızca SOAP + XML yerine).
• Durum bilgisi olmayan bir iletişimi vardır ve bu nedenle sunucu tarafı oturum depolamasına sahip olamaz. (SOAP'ın bu konuda bir kısıtlaması yoktur)
• Hipermediye hizmet eder ve istemciler hizmeti istemek için bu hiper ortamın içerdiği bağlantıları kullanır. (SOAP RPC, WSDL dosyasında açıklanan işlem bağlarını kullanır)
• URL değişikliklerinden sadece semantik değişikliklerden kaynaklanmaz. (RDF anlambilimi kullanmayan SOAP RPC istemcileri WSDL dosya değişikliklerine göre değişir.)
• Vatansız davranışı nedeniyle bir SOAP web hizmetinden daha iyi ölçeklendirilir.

ve bunun gibi...

Bir SOAP RPC web hizmeti tüm REST kısıtlamalarını karşılamıyor:

• istemci-sunucu mimarisi - her zaman
• vatansız - mümkün
• önbellek - mümkün
• düzgün arayüz - asla
• katmanlı sistem - asla
• isteğe bağlı kod (isteğe bağlı) - mümkün

İkinci soru ile başlayacağım: Web Hizmetleri nedir? , belli nedenlerden dolayı.

Web Hizmetleri esasen belirli işlevleri veya verileri ortaya çıkaran mantık parçalarıdır (belirsiz bir şekilde yöntem olarak bahsedebilirsiniz). Uygulayan müşteri (teknik olarak konuşmak, tüketmek kelimedir), sadece yöntemin kabul edeceği parametrelerin ne olduğunu ve döndüreceği veri türünü (eğer varsa ) bilmelidir .

Aşağıdaki link REST & SOAP hakkında her şeyi son derece berrak bir şekilde anlatıyor .

REST ve SABUN

Ne zaman (REST veya SOAP) ne zaman seçileceğini bilmek istiyorsanız, bundan geçmek için daha fazla neden var!

SOAP ve REST, farklı sistemlerin birbirleriyle konuşma yollarını ifade eder.

REST bunu tarayıcınızın web sunucularıyla olan iletişimine benzeyen teknikler kullanarak yapar: bir web sayfası istemek için GET, form alanlarında POSTing vb.

SOAP benzer bir şey sağlar, ancak XML bloklarını ileri geri göndererek her şeyi yapar. SOAP'ın bir diğer önemli bileşeni, hangi işlevlerin ve veri öğelerinin desteklendiğini açıklayan bir XML belgesi olan WSDL'dir. WSDL'ler programlı olarak hangi işlevlerin desteklendiğini "keşfetmek" ve programlama kodu saplamaları oluşturmak için kullanılabilir.

Bunun açıklayabildiğim kadar kolay olduğunu düşünüyorum. Lütfen, herkes beni düzeltebilir veya buna ekleyebilir.

SOAP, bağlantısı kesilmiş sistemler (internette olduğu gibi) bilgi / veri alışverişi için kullanılan bir mesaj biçimidir. XML mesajları ileri geri gidiyor.

Web servisleri SOAP mesajları gönderir veya alır. Hangi dilde yazılmış olduklarına bağlı olarak farklı çalışırlar.

SOAP ile ilgili sorun, HTTP yığınının arkasındaki ideallerle çakışmasıdır. Herhangi bir ara katman yazılımı, isteğin veya yanıtın içeriğini anlamadan HTTP istekleriyle çalışabilmelidir, ancak örneğin düzenli bir HTTP önbellek sunucusu, SOAP içeriğinin yalnızca hangi bölümlerinin önbellekleme için önemli olduğunu bilmeden SOAP istekleriyle çalışmaz. SOAP, HTTP'yi yalnızca kendi iletişim protokolü için bir proxy gibi bir paketleyici olarak kullanır.

REST, ağa bağlı uygulamalar tasarlamak için bir mimari tarzıdır. 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.

SOAP - "Basit Nesne Erişim Protokolü"

SOAP , iletilerin bir miktar aktarılması veya İnternet üzerinden az miktarda bilgi aktarılmasıdır. SOAP mesajları XML olarak biçimlendirilmiştir ve genellikle HTTP kontrol edilerek gönderilir .

REST - "Temsili Durum Transferi"

REST , fan ile sunucu arasında bilgi alma ve bilgi alma konusunda temel bir ilerlemedir ve kesin olarak tanımlanmış pek çok standardı yoktur. JSON , XML veya düz metin olarak bilgi gönderebilir ve kabul edebilirsiniz . SOAP ile karşılaştırıldığında hafif ağırlıklı .

SOAP Tabanlı Web Hizmetleri Kısacası, SOAP Tabanlı Hizmetler modeli dünyayı birbirini kontrol edemeyen, ancak yayınlanan sözleşmeleri onurlandırarak birlikte çalışmak zorunda olan eşdeğer akranların bir ekosistemi olarak görmektedir. Dağınık gerçek dünyanın geçerli bir modelidir ve meta veri tabanlı sözleşmeler SOAP Servis Arayüzünü oluşturur.

SOAP'ı XML Tabanlı Uzak Yordam Çağrılarıyla ilişkilendirebiliriz, ancak SOAP Tabanlı Web Hizmetleri teknolojisi esnek ve güçlü bir mesajlaşma modeline dönüşmüştür.

SOAP, tüm sistemlerin bağımsız olduğunu ve hiçbir sistemin başka bir iç ve iç işlevselliğin içsel bilgisi hakkında hiçbir bilgiye sahip olmadığını varsayar. Bu tür sistemlerin yapabileceği en fazla şey, birbirlerine mesaj göndermek ve onların harekete geçmesini ummaktır. Sistemler, onurlandırmayı taahhüt ettikleri sözleşmeleri yayınlar ve diğer sistemler de onlarla mesaj alışverişi için bu sözleşmelere güvenir.

Sistemler arasındaki sözleşmeler topluca meta veri olarak adlandırılır ve hizmet açıklamalarını, desteklenen mesaj alışverişi kalıplarını ve hizmet kalitelerini düzenleyen politikaları (bir hizmetin şifrelenmesi, güvenilir bir şekilde sunulması gerekebilir, vb.) İçerir. sistem tarafından gönderilecek ve alınacak verilerin (mesaj belgeleri) belirlenmesi. Belgeler, XML Şeması Tanımı gibi bir XML açıklama dili kullanılarak açıklanır. Tüm sistemler yayınlanmış sözleşmelerini onurlandırdığı sürece, çalışabilirler ve sistemlerin iç kısımlarındaki değişiklikler hiçbir zaman diğerlerini etkilemez. Her sistem kendi iç uygulamalarını sözleşmelerine ve sözleşmelerinden çevirmekten sorumludur

REST - Temsili Durum Transferi. Fiziksel protokol HTTP'dir. Temel olarak, REST, bir URL tarafından benzersiz bir şekilde tanımlanabilen web üzerindeki tüm farklı kaynaklardır. Bu kaynaklar üzerinde gerçekleştirilebilecek tüm işlemler, sınırlı sayıda fiil (“CRUD” fiilleri) ile tanımlanabilir ve bu da HTTP fiillerine eşlenir.

REST'ler SOAP'tan çok daha az “ağırdır”.

Web hizmetinin çalışması