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:
Eş : 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ışı