REpresentational State Transfer (Temsili Durum Transferi) istemci ile sunucu arasındaki iletişimde kullanılan bir mimaridir. Peki ama bu mimari temelleri nedir, problem(ler) neydi, nasıl çözdü ve faydaları neler?
Aşağıda bahsedeceğim mimari öğelerin her birisi bu mimariyi doğru anlamak ve kullanmak için çok önemlidir. Zira yapbozun parçaları ancak temellerini doğru anladığınızda oturacaktır aksi takdirde yalnızca yüzeysel kullanabilir ve haliyle yüzeysel fayda elde edebilirsiniz. O halde hadi başlayalım…
İstemci-Sunucu (client-server) iletişimi
İstemci sunucu tarafındaki altyapı vs. hakkında bir bilgiye ihtiyaç duymaz çünkü bağımlılığı olmaz. Bundan sebeple sunucu tarafında yapılacak altyapısal değişiklikler istemcileri etkilemeyeceğinden gevşek bağlılıktan (loose coupling) faydalanılır. İstemci sunucuya kendisi ile paylaşılmış dökümanlar doğrultusunda geçerli istekler gönderir ve geçerli yanıtlar alır.
Örneğin; HTTP protokolü kullanıldığında İstemci’ye geleceği adres ve varsa veri paketi paylaşılır.
Böylece hem istemci hemde sunucuyu geliştirenler mutlu, mesut yaşarlar 🙂
Durum bilgisi barındırmaması (stateless)
Sunucu tarafında bir oturum (session) vb. bilgi tutulmaz. Eğer sunucu tarafındaki servisin isteği işlenebilmesi için bir veri gerekiyorsa bu verinin kesinlikle her istek paketi içerisinde gönderilmesi gereklidir. Yani sunucu için istemciden gelen her istek durumsuz bir şekilde başlar ve istemcinin gönderdiği veriler ile geçici bir durum oluşur. Böylelikle oturum tutma ya da sürdürme gibi ciddi kaynak tüketen ve ölçeklenmeyi engelleyen problemler ile uğraşmamız gerekmez.
Örneğin; kimlik doğrulaması için gerekli olan access_token ya da user-pass bilgisi her HTTP istek paketinde header içerisinde yer almalıdır.
Önbelleğe alınabilir olması (cacheability)
Sunucu tarafından istemciye istek yanıtının önbelleğe alınıp/alınamayacağı ya da ne süre ile önbelleğe alınabileceği hakkında bilgi verilir. Bu sayede istemci sunucuya tekrar istek göndermeden önce varsa kendi tarafındaki önbelleğe bakar ve önbellek geçerli ise gereksiz istekler göndermeyerek ağ (network) tarafında ve dolaylı olarak performans noktasında tasarruf sağlanır.
Katmanlı sistem (layered system)
İstemci yalnızca istek göndereceği sunucuyu bilir. İstek gönderdiği sunucu arka tarafta belki 10 farklı sunucuya istek gönderip verileri toparlayıp sunuyor olabilir ya da isteği yük dengeleyici (load balancer) sistemler ile işliyor olabilir. Aslında burada katmanlı olabilen taraf sunucu kısmıdır.
Tek tip arayüz (uniform interface)
Her parçanın bağımsız olarak gelişmesine imkan sunar ve böylelikle mimariyi, dolayısıyla iletişim sürecini basitleştirir.
Talep üzerine kod (code on demand) [opsiyonel]
REST’teki tek isteğe bağlı kısıtlamadır. Nadiren zorunluluklardan dolayı kullanılıyor olsa da aslında gevşek bağlılığa (loose coupling) aykırı olduğundan kullanımı pek tercih edilmez. Burada ana konu sunucunun istemciye çalıştırması için bir kod parçacığı iletiyor olması durumudur. Günün sonunda temelde akışın yönetimi sunucu tarafında olduğundan bir eylem sonucunda alınması gereken aksiyonlar ile ilgili yine sunucudan alınan kod parçacıklarının kullanılması gerekebilir. Bu kod parçacıklarının güvenlikleri ve bütünlüklerinin teğitini sağlamak için bir çok kriptoloji yöntemi kullanılabilir.
Problem Neydi?
Web servislerin tarihsel akışına bakacak olursak REST’in ilk kıvılcımları SOAP sonrasında ortaya çıkmıştır. SOAP protokolü üzerinden çalışan servisler çok kullanışlı ve her türlü ihtiyacı karşılayabiliyorlardı fakat performans ve ölçeklenebilirlik noktasında sorunları vardı. Sonuçta bu bir protokoldü ve yalnızca WSDL standartlarına uygun bir XML üzerinden iletişim sağlıyordu. Bu sorunları gören Roy Fielding, Kaliforniya Üniversitesi‘ndeki doktora tezinde REST’i bizlere sundu.
Peki bu problemler için çözüm önerisi neydi?
Öncelikle kullanılacak bir protokol değil, mimari sunmuştu. Bu sayede istenilen protokolde kullanılması mümkün ama genellikle web uygulamaları geliştiricileri tarafından HTTP protokolü üzerinde kullanılıyor. SOAP’da WSDL standartları üzerine inşa edilmiş XML üretmemiz gerekiyordu. Oluşturduğumuz XML içerisinde o anda kullanmayacağımız bir alan olsa dahi bunu veri paketi içerisine koymak zorundayız. REST mimarisine uygun hazırlanan bir serviste ise yalnızca ihtiyaç duyulan alanların gönderilmesi yeterliydi. Bu çözüm sunucu ve istemci arasındaki veri trafiğini ve bu trafik arttıkça artan kaynak gereksinimini ortadan kaldırdı. İşte bu bağımlılığın ortadan kalkması ile ölçeklenebilir servisler hazırlayabildik.
Faydaları
Aslında bana göre en temel faydası basitliktir. Bu basitlik hem servisin oluşturulması, hem servise entegre olunması hem de servisin dökümantasyonu noktasında işimizi kolaylaştırmaktadır.
Dilediğimiz bir formatta (genellikle bilinen XML ve JSON formatlarında) dilediğimiz veri kontratını oluşturabiliriz.
İsteğin işlenebilmesi için tanımladığımız veri kontratındaki alanların tamamının gönderilmesi gerekmez. Bu sayede iletişim sürecindeki gövde içeriği olabildiğince optimize edilmiştir.
Veri tipini tutabilir, bu sayede int olarak tanımlamış olduğunuz bir alan sunucuya giderken ya da sunucudan istemciye giderken int olarak aktarılabilir.
Yaygın kullanıma bağlı olarak servis referansları oluşturma araçları vardır. Hatta OpenAPI ile github.com/OpenAPITools/openapi-generator aracı üzerinden bir çok dil ve altyapı için otomatik olarak kod üretimi mümkündür.
The goal of REST is to increase performance, scalability, simplicity, modifiability, visibility, portability, and reliability.
en.wikipedia.org/wiki/Representational_state_transfer
Umarım REST mimarisi ile ilgili yeni bilgiler öğrenmiş ya da bilgilerinizi tazelemişsinizdir 🙂 Bir sonraki yazıda RESTful API olarakta bilinen REST API konusunu ele alacağız.
REST mimarisine sadık geliştirildiği iddia edilen saçma sapan servisler ve onları size sunanlar ile yıpranmadığınız keyifli günler dilerim…
