REST istemci-sunucu arasında hızlı ve kolay şekilde iletişim kurulmasını sağlayan bir servis yapısıdır. Açılımı Representational State Transfer olan bu ifadeyi Türkçe’ye Temsili Durum Transferi diye çevirebiliriz. Bu yazıda REST’in genel mimarisini, nasıl çalıştığını, artılarını, eksilerini ve SOAP ile arasındaki farklılıklarını irdelemeye çalışacağız.

REST, servis yönelimli mimari üzerine oluşturulan yazılımlarda kullanılan bir veri transfer yöntemidir. HTTP üzerinde çalışır ve diğer alternatiflere göre daha basittir, minimum içerikle veri alıp gönderdiği için de daha hızlıdır. İstemci ve sunucu arasında XML veya JSON verilerini taşıyarak uygulamaların haberleşmesini sağlar. REST standartlarına uygun yazılan web servislerine RESTful servisler diyoruz. Yani RESTful denildiğinde aklınıza çok farklı bir kavram veya dünya gelmesin.

REST stateless‘dır, yani durum bilgisini saklamaz. Biraz daha açalım; REST standartlarında istemci-sunucu arasında taşınan verilerde ekstra başlık bilgileri saklanmaz, istemciye ait detaylar bulunmaz, bu bilgiler istemci-sunucu arasında taşınmaz. Dolayısıyla servis yönelimli uygulamalarda REST bize lightweight bir çözüm yapısı sunar.

Teorik olarak SOAP bir protokol, REST ise bir kurallar dizisidir. Bu iki terimi doğrudan kıyaslamak biraz yanlış olsa da, SOAP ile geliştirilen bir uygulama ile REST ile geliştirilen bir uygulamayı kıyaslamanın REST’in daha iyi anlaşılmasını sağlamak için uygun bir yol olacağını düşünüyorum. O zaman kıyaslayalım:

SOAP servisleri RPC(Remote Process Call yani uzaktaki bir prosedürün çağrılması) çalışma yöntemini kullanır, WS-* gibi güvenlik protokollerini içerisinde barındırır, state bilgisini request ve response’larda saklar. Ancak REST’te bu durum daha farklıdır. REST servisler doğrudan bir URL çağrılarak çalışır, arada ek bir bileşen, yöntem veya protokol kullanılmaz.

SOAP bir servisi uygulamanıza dahil edebilmeniz için servisin WSDL’ına ihtiyaç duyarsınız, proxy sınıfları oluşturmanız gerekir, uzaktaki metotları tetikleyecek bileşenlere ihtiyaç vardır. DISCO, UDDI vs. derken aslında işin arka planında baya detay olduğunu görürsünüz. Yani özet olarak istemci, SOAP bir servisle ilgili herşeyi bilmek zorundadır, belirli standartları yerine getirilmeden SOAP bir servisi çağıramaz. Ancak REST ile yazılmış bir servisle çalışmak için ihtiyacınız olan tek şey URL. Bir URL’yi çağırırsınız, URL size JSON veya XML döndürür, dönen cevabı parse edersiniz ve servis entegrasyonunuz tamamlanır. Yani teorik olarak istemci uygulama REST bir servisin yapısını ve detaylarını bilmek zorunda değildir. REST’in bu basit standartları dışında uyulması gereken bir kural yoktur, son derece esnek bir yapı vardır.

RESTful bir servisi çağırmak için karşınızdaki kurum size www.siteadi.com/product/12345 gibi bir URL verir ve bu adresi çağırdığınızda ID değeri 12345 olan ürünün detaylarının size JSON olarak döneceğini söyler. Size kalan tek iş bu URL’yi back-end’de WebRequest vb. sınıflarla veya client-side’da AJAX fonksiyonları vasıtasıyla çağırmak ve gelen JSON verisini uygun formatta görüntülemek olacaktır.

Yazı için internetten grafik, resim vb. yazıya renk katacak bir unsur ararken aşağıdaki resmi buldum. REST ve SOAP arasındaki fark için çok anlamlı bir benzetme olmuş. İngilizce metni okumadan da resim çok şey anlatıyor bence.

RESTful servisler veri iletiminde farklı HTTP metotlarını kullanmaktadır. Bunlar GET, POST, PUT, DELETE metotlarıdır. GET okuma, POST yeni kayıt ekleme(insert), PUT kayıt güncelleme(update), DELETE ise kayıt silme işlemi için kullanılır. Yapılan HTTP request’i için çağrılan URL ile beraber HTTP method bilgisi bahsi geçen 4 metottan biri olarak seçilir ve sunucu yapılan talebin kayıt üzerine nasıl etki edeceğini buna göre belirler.

Basit yapısı, kolay uygulanması, hızlı çalışması, esnek olması… bunlar RESTful servislerin artı yönleri. RESTful servislerinin bazı eksi yönleri de var tabii ki. Güvenlik bunlardan biri. SOAP servislerde standart lar gereği birçok güvenlik mekanizması otomatik olarak elinizin altındadır. Ancak RESTful servislerde güvenlik konuları geliştirilen yazılımın bir parçasıdır. İletişim seviyesinde güvenlik(transport level security) genellikle token aracılığıyla yapılır. İstemci kritik işlemleri çağırmadan önce bir login isteği gönderir. Bu istek sonucunda istemciye sessin token vb. bir değer verilir ve bundan sonra yapacağı istekler bu token değeri ile yapılır. Mesaj seviyesinde güvenlik(message level security) konusu da yine geliştirilen yazılımların içerisinde çözüm bulunması gereken bir konudur. Tabii ki bazı üçüncü parti araçları kullanarak hem iletişim hem de mesaj seviyesinde güvenlik fonksiyonlarını yazılımlarınıza daha kolay şekilde uygulayabilirsiniz.

REST mimarisini ve RESTful servislerin genel yapısını incelemeye çalıştık. Buradaki başlıkları daha detaylandırmak mümkün, hatta yazıda yer veremediğimiz farklı başlıklar da var. Burada amacımız REST’i temel yönleriyle ve bilhassa SOAP servislerine karşılık gelen yönleriyle irdelemekti. Umarım faydalı bir giriş yazısı olmuştur. Sıfırdan bir RESTful API yazacak olursanız veya bir şablon üzerine RESTful servisler geliştirecek olursanız Twitter, Amazon, Google gibi bu konulara yön veren ve trendleri belirleyen kurumların API’lerini incelemenizi tavsiye ederim.