REST yapmanın doğru yolu nedir?


36

Bugünlerde herkes SOA yapıyor , bazıları aslında ne hakkında olduğunu anlamıyor olsa bile. Yani yanlış yapıyorlar. Bunu bir analoji olarak kullanarak, REST'in ne olduğunu biliyorum (ya da en azından benim yaptığımı düşünüyorum) ve bazılarını yapmak istiyorum. Ama doğru yapmak istiyorum.

Öyleyse sorum şu ki, REST yapmanın doğru yolu nedir?


1
Stack Overflow 'rest' etiketi wiki , Stack Exchange ağı bağlamında kanonik kaynağa geldiği kadar yakın gözüküyor
gnat

17
Sadece bir süreliğine gözlerimi kapattım ... belki bisiklete binip sonra uzandım.
Edward Strange

REST temel olarak sadece bir etki alanı çağırmak için alanim.com.tr/accounts ve bir HTTP fiili gibi bir url kullanmak değil midir? Fiil, veri almak, oluşturmak, güncellemek veya silmek isteyip istemediğinizi gösterir? REST düşündüğümde düşündüğüm şey bu.
Çörek Adam

2
@Nick, bu en yaygın yorumdur, 'gerçek şey' grok için çok daha zordur ve (söyleyebildiğim kadarıyla) gerçekte herhangi bir yerde uygulandığını bulmak çok daha zor ... (
Wilk'in

3
@ Anlayışınız REST değil, HTTP üzerinden RPC .

Yanıtlar:


30

RESTful bir web uygulaması oluşturmayı öğrenmenin birçok yolu vardır ve hayır, benzersiz bir doğru yol yoktur. RESTful bir standart değildir, ancak bir dizi standart kullanır (HTTP, URI, Mime Type, ...).

Bununla başla: Eşime REST'i Nasıl Açıklarım?

Ardından şuna devam edin: RESTful Web Services Yemek Tarifleri

Ve sonra web uygulamaları geliştirmek için tüm çabanızı koyun çünkü öğrenmenin en iyi yolu deneyler yapmaktır ve hatalarınızdan çok şey öğrenebilirsiniz;)

İlk web uygulamalarınız tamamen RESTful olmayacaksa endişelenmeyin: Bunu yapmanın yolunu bulacaksınız!

Öyleyse, Obi-Wan Kenobi'den "güç seninle olsun!" ;)

DÜZENLE

Tamam, daha spesifik olalım. RESTful webapp yapmak istiyorsun, ha? Dediğim gibi, bunu yapmanın birçok yolu var, ancak bu ana kılavuzdur.

Tanım

REST (Temsili Durum Aktarımı) , dağıtılmış sistem için bir yazılım mimarisinin stilidir (WWW gibi). Standart değildir ancak bir dizi standart kullanır: HTTP, AJAX, HTML, URI, Mime Type, vb. Bir kaynağın kendisi hakkında değil, bir kaynağın temsilinden bahsediyoruz. 'REST'i karıma nasıl açıkladım' dan alınmıştır:

: Bir web sayfası bir kaynaktır?

Ryan : Bir nevi. Bir web sayfası bir kaynağın temsilidir. Kaynaklar sadece kavramlardır.

Mimarlığın Kısıtlamaları

  • İstemci-Sunucu : istemci ve sunucu Tekdüzen Arayüz ile ayrılmıştır (aşağıda açıklanmıştır).
  • Vatansızlık : sunucu-müşteri iletişimi sunucuya belirli bir müşteri durumunu kaydetmeden yapılır.
  • Önbelleğe alınabilir : istemcinin önceden yapılmış isteklerin yanıtları önbelleği olabilir.
  • Katmanlı Sistem : müşteri doğrudan bir sunucuya bağlı olup olmadığını veya iletişim aracılar aracılığıyla yapılıp yapılmadığını bilmiyor.

Düzgün Arayüz

  • Kaynakların Tanımlanması : Her kaynak bir URI tarafından tanımlanmalıdır.
  • Protokol : İletişim istemcisi ve sunucusuyla iletişim kurabilmek için önce bir protokol yapılması gerekir. Her istekte doğru MIME Türü (uygulama / xml, metin / html, uygulama / rdf + xml, vb.), Doğru başlıklar ve doğru HTTP yöntemi bulunabilir (aşağıdaki CRUD açıklamasına bakın).

REZİL

Tamam, kaynakları tanımlamak için URI kullanabileceğimizi gördük, ancak eylemler için başka bir şeye ihtiyacımız var (ekleme, değiştirme, silme, vb.): CRUD'a hoş geldiniz (Oluştur, Oku, Güncelle ve Sil).

  • Oluşturun { HTTP POST } { SQL: INSERT } => Yeni bir kaynak oluşturmak
  • Okuma { HTTP: GET } { SQL: SEÇ } => olsun bir kaynak
  • Güncelleme { HTTP: PUT } { SQL: UPDATE } => Bir kaynak değiştirmek
  • Sil { HTTP: DELETE } { SQL: DELETE } => bir kaynağı sil

Şimdi, PUT ve DELETE ile ilgili bazı teknik problemler ortaya çıkabilir (HTML formunu alırsınız): geliştiriciler her 'PUT' ve 'DELETE' talebi için POST kullanarak bu sorunu atlarlar. Resmen, PUT ve DELETE kullanmanız gerekir. Bu arada, ne istersen yap. Tecrübelerim beni her zaman POST ve GET kullanmaya zorluyor.

--- Sonraki kısım kullanılmalı, ancak bu bir REST bağı değildir: Bağlantılı Verilerle ilgilidir ---

URI

Teknik detaylardan soyut URI! Aşağıdaki şekilde URI'ye veda edin:

http://www.example.com/index.php?query=search&id=9823&date=08272012

URI'yi yeniden tasarlayın! Yukarıdaki bağlantıyı alın ve aşağıdaki şekilde değiştirin:

http://www.example.com/search/2012/08/27/9823

Bu çok daha iyi, ha? Tarafından yapılabilir:

Başka bir şey: farklı kaynakları temsil etmek için farklı URI kullanın:

Dikkat : about.html ve about.rdf dosya değildir! Bir XSLT dönüşümünün sonucu olabilirler!

İçerik Müzakere

Bu noktaya ulaştıysanız, tebrikler! Muhtemelen, daha soyut kavramlar almaya hazırsınız çünkü Semantic Web teknik ayrıntılarına giriyoruz;) Müşteriniz bir kaynak istediğinde, genellikle aşağıdaki isteği yapar:

GET http://www.example.com/about
Accept: application/rdf+xml

Ancak, sunucu farklı bir URI'ye sahip olduğundan about.rdf ile yanıt vermez ( http://www.example.com/about.rdf ). Öyleyse, 303 modeline bir göz atalım ! Sunucu bunu döndürecek:

303 See Other
Location: http://www.example.com/about.rdf

Ve müşteri aşağıdaki gibi verilen bağlantıyı takip edecektir:

GET http://www.example.com/about.rdf
Accept: application/rdf+xml

Son olarak, sunucu istenen kaynağı verecektir:

200 OK
about.rdf

Endişelenmeyin: müşteri başvurunuz hiçbir şey yapmaz! 303 deseni sunucu uygulaması tarafından yapılmalıdır ve tarayıcınız gerisini halleder;)

Sonuç

Genellikle teori uygulamadan çok uzaktır. Evet, artık RESTful bir uygulamayı nasıl tasarlayacağınızı ve geliştireceğinizi biliyorsunuz, ancak yukarıdaki kılavuz sadece bir ipucu. Web uygulamaları oluşturmanın en iyi yolunu bulacaksınız ve muhtemelen teorinin istediği gibi olmayacak. Kahretsin: D!

Kaynakça

RESTful Web Servisleri, Sameer Tyagi

REST API'leri köprü metin odaklı olmalı, Roy Thomas Fielding

RESTful Web servisleri: Temel bilgiler, Alex Rodriguez

Webber REST İş Akışı


1
Karşılaştığım en eksiksiz kılavuz olan bu bağlantıyı eklemeyi düşünebilirsiniz .
Benjol

PUT ve POST'un anlamları değiştirilirken kullandıklarını gördüm (cevabınızla ilişkili olarak): POST -> create, PUT -> update. Hangi anlamın daha yaygın kullanıldığı konusunda bir fikriniz var mı?
Andres F.

@Andres F .: jcalcote.wordpress.com/2008/10/16/… diyor ki: Belirtilen kaynağın (URL) tüm içeriğini gönderiyorsanız Create = PUT. Create = POST, sunucuya belirli bir alt algoritmayı kullanarak, belirtilen kaynağın bir altını oluşturmak için bir komut gönderiyorsanız. Update = Belirtilen kaynağın tüm içeriğini güncelliyorsanız PUT. Update = POST'tan, sunucunun belirtilen kaynağın bir veya daha fazla alt öğesini güncellemesini istiyorsanız.
Wilk

@Benjol: Öneriniz ile düzenleme yapacağım;) Teşekkürler!
Wilk

1
@Wilk Dikkate alınması gereken birçok şey! Muhtemelen neden hiç kimse bu hakkı
alamıyor

5

bir REST İncil kitabı ya da bir şey ....

İncil kitabı gerekmez; Aynı kesin soruları vardı ve bu üç makaleyi okuyarak REST hakkında ihtiyaç duyduğum ya da bilmek istediğim her şeyi öğrendim:

  1. Yeni Başlayanların Net Tuts'tan HTTP ve REST'e Giriş +
  2. RESTful Web servisleri: IBM developerWorks'ün temelleri
  3. RESTful HTTP pratikte InfoQ dan

Ama doğru yapmak istiyorum.

Yukarıdaki makalelerde okuyacağınız gibi, anahtar, uygulamanızın erişilebilir parçalarını mevcut HTTP "fiiller" kullanılarak oluşturulabilen, alınabilen, güncellenebilen veya silinebilen "kaynaklar" olarak düşünmektir: GET, PUT, POST , SİL.

Ayrıca, PUT ve POST arasındaki farkı ve ne zaman kullanacağınızı da öğrenin. GET, PUT VE DELETE kesin işlem yapılmalı, POST olmamalıdır.

Ayrıca, müşteriye geri iletilirken HTTP durum kodlarını doğru şekilde kullanın .

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.