REST vs RESTful vs "normal" web hizmeti - aynı mı değil mi?


21

REST ve / veya RESTful uygulamalarıyla ilgili birkaç tanım ve tartışma okudum, ancak bunun gerçek anlamını hala anlamadım.

Genellikle GET üzerinden veri toplayan ya da POST üzerinden veriyi bazı web servislerine (genellikle bir PHP betiği) gönderen uygulamalarla çalışıyorum.

Şimdi, bu bir RESTful uygulaması mı? Eğer değilse, bir RESTful uygulaması ne olurdu? RESTful konsepti ile şu ana kadar çalıştığım konsept arasındaki fark nedir? Lütfen bir örnekle açıklayınız.

Ayrıca, birisi REST ve birisi RESTful uygulamalar hakkında konuşuyor. REST teriminin teorik konsepte karşılık geldiğini, özel uygulama hakkında konuşurken RESTful'ın kullanıldığını gördüm. Bu doğru mu veya REST ve RESTful uygulamalar arasında gerçek farklılıklar var mı?


1
SADECE GET veya POST parametrelerinden bilgi almak için tüm Sunucularınızı oluşturabiliyorsanız (kesinlikle aramadan önce yerel olarak kaydedilen hiçbir şey yok), REST'e uygun şekilde başvuruyorsunuz demektir. Başka bir deyişle, sunucu MVC'deki modelin kontrolde olmadığı, ancak bir görevi yerine getirmesi için verilenleri kullandığı rolünü oynar. Umarım bu biraz daha iyi açıklar.
Neil

@Neil Ben diğer taraftayım - mobil uygulama. Web servisini kullanan ve bununla POST ve GET üzerinden iletişim kuran bir istemci. Tüm web servisi başkası tarafından yaptırılmış ve tüm yaptığım bunları kullanıyordu. Ancak terminoloji beni şaşırttı. Yani, eğer HTTP kanalı ve HttpGet / HttpPost nesneleri kullanıyorsam, o zaman bir RESTful uygulamasıyla uğraşıyorum, değil mi?
deviDave

Şart değil. Bazı kısıtlamaları ihlal edebileceğinden, sunucunun nasıl yapıldığını bilmiyorsanız, RESTful bir uygulama olup olmadığını bilmenin bir yolu yoktur. Bu, tutarlı sonuçlar verirse büyük olasılıkla RESTful dedi.
Neil

@Neil Oh, şimdi anladım. RESTful sunucuda yapılır. Ve eğer bir isteği bir istekle gönderirsem (her parametre ayrı ayrı değil) o zaman muhtemelen bir REST yaklaşımıdır. Bir müşteri (mobil uygulama) olduğu sürece, REST olup olmadığının kodlamanın aynı olması umrunda değil. Doğrumu anladım?
deviDave

2
RESTful hem sunucu hem de istemcidir, ancak yalnızca istemciyi görebiliyorsanız, yalnızca müşterinin kısıtlamaları yerine getirip getirmediğini bilemezsiniz. Tüm demek istediğim buydu. REST ile demek istediğim, giriş yapmanız gerekiyorsa, kullanıcı adınızı ve şifrenizi yazmanız gerekir. Sunucu girişi doğrular ve kullanıcının karma anahtarını veritabanına kaydeder ve geri döndürür. Artık giriş gerektiren bir işlem yapmanız gerektiğinde, her zaman kullanıcının karma anahtarını geçirirsiniz. Sunucu, giriş yaptığını "unutur" ancak oturum açma durumunuzu doğrulamak için kullanıcı karma'sını kullanır. RESTful olmasaydı, sunucu giriş yaptığınızı hatırlardı. Farkı anladınız mı?
Neil

Yanıtlar:


13

RESTful uygulamaların temel özellikleri şunlardır: Tüm iletişim http GET, POST, PUT, DELETE üzerindendir ve tüm öğeler formun standart bir URL'si ile adreslenir, http://your.site.com/salesapp/salesperson/0000001/detailsyani sadece parametresiz saf bir URL vb. , POST, PUT, DELETE, ne yapmak istediğinizi belirler.

Bunu yapmanın temel nedeni, otomatik olarak yük dengelemeli, üzerinde başarısız vb. Gibi vatansız bir servise sahip olmanızdır.

Programın saflığı, müşteriyi herhangi bir arka uç uygulamasından tamamen ayıran, çok temiz bir arayüz sağlar.


Oh, şu ana kadar PUT veya DELETE kullanmamıştım (mobil uygulamalar genellikle sadece GET ve POST yapar), fakat bu gerçekten şu anda yaptığım ve yaptığım şeye benziyor. Sadece müşteriler REST * terimlerini kullanmadılar, daha ziyade "web service" ve "php script" kullandılar
deviDave

2
James, sorgu parametrelerinin neden kaçınılması gerektiğini açıklayabilir misin? Örneğin, sahte bir hiyerarşi getirmeden kaynakların belirli bir şekilde filtrelenmesini istediğimi nasıl ifade edebilirim?
Gary Rowe

3
@GaryRowe: URL (parametresiz), işlemek istediğiniz kaynağı tanımlar. Hala parametrelere sahip olabilirsiniz ancak bunlar kaynağı tanımlamakta kullanılmazlar. Örnek: Bir dizindeki bir GET (/ ile biten bir URL) dizindeki kaynakların bir listesini döndürmelidir. URL'deki bir parametre, filtre veya sıralama düzeni veya benzeri bir şey belirtmek için kullanılabilir.
Martin York

1
Sağol Loki. James, sorgu parametrelerinin yanıltıcı olabilecek herhangi bir koşulda kullanılmasına izin vermediği anlaşılıyor olması nedeniyle cevabını düzenlemek isteyebilir. Aslında, bir dizindeki kaynakların listesinin kendi başına bu kavramı ifade eden bir kaynak olduğuna dair ilginç bir gözlem vardır.
Gary Rowe,

REST, uygulamanın URL tabanlı olmasını da gerektirmez, ayrıca GET, POST, DELETE, vb. Gibi fiillere sahip olmanızı da gerektirmez. Ancak, bir WebApp için URL, tek seçenek ve yukarıda belirtilen fiillerdir.
Nawaz

6

REST, Temsili Devlet Transferi anlamına gelir. Yazılımınız REST Kısıtlarına uygunsa, RESTful olarak kabul edilir.

Şimdi, utanmadan Vikipedi'den kopardığım için, bu gerçekten ne anlama geliyor? Bir müşteri ve sunucu arasında ileri geri iletişim kurmak için GET, POST, PUT, DELETE ve diğer birkaç nadir komut gibi dahili HTTP komutlarını etkili bir şekilde kullanmak anlamına gelir.

Ne yapıyorsun onun gibi bir RESTFul uygulaması. Ancak, iyi tasarlanmış ve önemsiz RESTFul web servislerinin yığınları arasında büyük bir fark vardır . Örneğin, GET'in diğer ucundaki PHP kodu, bir GET salt okunur bir işlem olarak görüldüğü için yanlış sayılabilecek durum değişikliğini gerçekleştirebilir. POST (yeni) ve PUT (değiştirme) de nasıl kullanıldığı arasında ince farklılıklar vardır.

Bununla ilgili Wikipedia makalesi gerçekten çok iyi, bu yüzden burada duracağım.


Şimdiye kadar içerik almak için GET (HttpGet) ve bir veritabanının içeriğini girmek / değiştirmek için POST (HttpPost) kullandım. Bunu HttpPost'a bir parametre olarak gönderdim ve web sunucusundaki PHP betiği bu parametreleri SQL koduna dönüştürdü. Bu bir RESTful uygulaması mı? PHP betiğinin ne kadar iyi yapıldığına değil, bir konsepte ilgi duyuyorum. Yapmadım.
deviDave

2
İçeriği değiştiriyorsanız , her zaman POST kullanmaktan daha deyimsel REST olan PUT kullanımını araştırırdım .
Martijn Verburg

Evet, böyle bir durumda PUT kullanırdım.
deviDave

GET'in doğru bir şekilde uygulanması gerektiğine dikkat çektiğiniz için +1 (yani kesin değildir) Erken günlerde böyle bir temel hata.
Gary Rowe

@deviDave Bir kaynağın bir bölümünü güncellemek için tasarlanmış PATCH'a da bakmak isteyebilirsiniz. Martin haklı olarak işaret ettiği gibi, PUT tüm kaynağı değiştirmek içindir.
Gary Rowe

4

Daha ileri gitmeden önce, bu ilgili soru size yardımcı olabilir

REST ve RESTful arasındaki fark sadece anlamlıdır. REST, müşteri-sunucu ilişkisine uygulanan mimari bir stildir. RESTful, müşterilerinize REST kullandığınızı söylemenin bir yoludur.

Pek çok web uygulamaları RESTful olduğunu iddia ama aslında sadece kısmen conformant edilir için DİNLENME Kısıtlar (Martijn Verburg da onun cevabını başvurulan gibi). Onları burada listeleyeceğim ancak makaleyi okumanızı şiddetle tavsiye ediyorum:

  • Müşteri sunucusu
  • cacheable
  • Katmanlı sistem
  • Talep üzerine kod (isteğe bağlı)

Müşteri tarafında çalıştığınızdan bahsettiğinizden beri, bir REST mimarisinin size neler vereceğini ve bağlayıcı bir müşteri olarak ne bekleyeceğini görmek faydalı olabilir. REST HTTP olmasa da, REST'in ne olduğunu destekleyen en popüler protokoldür, bu yüzden örneğimi bu çerçeveye yerleştireceğim.

Müşterinizden şunları yapmanız bekleniyor:

  • İlgili işlemleri gerçekleştirmek için HTTP fiillerini (örneğin, GET, POST, PUT, DELETE, OPTIONS, PATCH) kullanın
  • Başlıkları kabul et ve İçerik Türü başlıklarını anlayın (örneğin, daha önce hiç görmediğiniz bir XML alırsınız, ancak kullanıcılarınıza sunmak üzere bir istemci tarafı etki alanı modeli oluşturmak için başvurulan bir XSD kullanabilirsiniz)
  • anladığınız bir İçerik Türü'nde sunulan bağlantıları izleyin (örneğin <link rel="pay" href="http://example.org/orders(1)/payment">, HTML’nizde, kredi kartı numarası gibi ödeme ayrıntılarını gösteren bir XML içeren bir gövdeye sahip bir POST aracılığıyla bir ödeme kaynağı oluşturmak için bir devlet geçişi ifade ettiği sonucuna varması için kullanıcınıza veya uygulamanıza ulaşın) , miktar vb.
  • Çok çeşitli HTTP durum kodlarına doğru tepki ver

Yukarıdakileri yaparsa, bir REST istemcisi olarak düşünülebilir, bunu bir "RESTful uygulaması" olarak adlandırmak isteyebilirsiniz, ancak bu, müşteri tarafında REST kullandığınızı ve bunun da yanlış olmasını en iyi şekilde yanlış yaptığınızı belirtir. dönem.


3

RESTful, arayüzün okunabilen ve güncellenebilen (ve muhtemelen silinen) bir nesne kümesi olduğu anlamına gelir. Yani çok parametreli sorgu yoktur (okumak istediğiniz nesne sadece parametredir) ve sunucudaki herhangi bir şeyi değiştiren tek bir işlem türü vardır, yeni durumun yüklenmesi.

Bu sınırlamalar tüm isteklerin önemsiz olmasını sağlar (birden fazla kez göndermenin bir kez göndermeleri için herhangi bir ekstra etkisi yoktur). Bu önemlidir, çünkü ağ her zaman başarısız olabilir ve herhangi bir istek veya yanıt veremez ve belirsiz isteklerle tekrar gönderirsiniz ve karmaşık bir kurtarma işlemi yapmak zorunda kalmazsınız.


1. paragraf için oy verin. Çok özlü. Teşekkürler!
deviDave

Bir şey daha, doğru anlamış mıyım görmek için. Ben (uygulamam) REST hizmetinin müşterisiyse, bir hizmetin RESTful olup olmadığını kodlamam her zaman aynı olduğundan istemem (httpget, httppost, vs.)? Bu ilke sadece bir sunucu betiği / uygulaması sahibi için önemli mi?
deviDave

REST, arayüzün anlamını tasarlamak için bir rehberdir. Altta yatan teknoloji, arabirimin RESTful olup olmadığına ilişkin HTTP'dir (ancak, XML-RPC veya SOAP gibi diğer katmanlar, RESTful arabirimleriyle ilgili değildir), bu nedenle her zaman aynı httpget, httppost vb. Kullanırsınız. Ancak ağ arızalarını farklı şekilde ele alırsınız.
Jan Hudec

eklemek için, SMTP, RESTful bir arayüzdür, GET, PUT vb. farklı fiiller ve farklı bir temel protokol kullanmasına rağmen, konsept aynıdır - bir sunucuya idempotent fiil tabanlı komutlar gönderirsiniz.
gbjbaanb

Tüm REST istekleri önemsiz değildir. Örneğin, bir POST'u birçok kez vermek, birçok yeni kaynağa yol açacaktır.
Gary Rowe
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.