REST ve RESTful

Web Service yazısının ardından, okumalarda karşılaştığım ve terminoloji bağlamında biraz akıl karışıklığı yaratan bazı konuları öğrendiklerim üzerinden ifade etmeye çalışacağım.

AA

Bunlardan ilki REST ve SOAP yazısında da kenara not ettiğim REST ve RESTful üzerinde olacak. İlgili yazıda kısaca şu tanımı yapmıştım: “REST standartlarına uygun yazılan web servislerine RESTful servisler denir”. Şimdi bu tanımı biraz daha detaylandırarak en azındam benim için kafa karışıklığı yaratmış bazı hususları çözümleyeceğim.

REST ve RESTful

REST (Representational State Transfer), bir yazılım mimarisi (software architecture) stili olarak ifade edilebilir. Bu tanım için Roy Fielding‘in1 2000 yılında yayınlanan Architectural Styles and the Design of Network-based Software Architectures başlıklı tezini temel alabiliriz; “REST web’in mevcut teknolojisini ve protokollerini temelde kullanan bir mimari stil (architectural style)’dir2. RESTful ise, genellikle böyle bir mimariyi uygulayan web servislerini ifade etmek için kullanılır. Ancak, RESTless veya RESTlike gibi servislere de denk gelinmesi olası. Bu bağlamda, RESTful’un kesinlikle REST mimarisini kullandığını söylemek doğru olmayacaktır3.

Bu ayrımı şu şöyle netleştirebiliriz; REST’in temelde şu mimari stil prensipleri çerçevesinde geliştirilmesi beklenir4 5:

Client-Server
REST uygulamaları, uygulama verilerini ve durumunu yöneten bir sunucuya sahiptir. Server, kullanıcı etkileşimlerini idare eden bir client ile iletişim kurar. İki bileşen birbirinden ayrıdır ve parçalar bağımsız olarak güncellenebilir ve geliştirilebilir. Client, server tarafındaki veri kaynağı ile ilgili hiçbir şey bilmez. Server sadece kendisine gelen istekler doğrultusunda değer döner. Böylece server daha basit ve scalable olur.
Stateless
server client ile ilgili hiç bir bilgiyi tutmamalıdır. Client tarafından gerçekleştirilen her istek (request), server’in response dönebilmesi için geçerli bilgiyi taşımalıdır. Client ayrımı request esnasında göndereceği bir token veya kimlik bilgisi ile gerçekleştirilir.
Cacheable
Server response’ların önbelleklenebilir olup olmadığını belirtmelidir. Böylece, altyapılar ve client’lar performansı artırmak için mümkün olduğunda önbellekleyebilir. Önbelleğe alınamayan bilgileri elden çıkarabilirler, böylece hiçbir client stale data kullanmamış olur.
Uniform Interface
REST’in en öne çıkan özelliği ve kuralıdır. Fielding bu kural ile ilgili olarak, “REST mimari stilini diğer ağ tabanlı stillerden ayıran en temel özellik, bileşenler arasında tek tip bir arayüze vurgu yapmaktır” der. Client ile server arasındaki ortak bir arayüzün (interface) olması ile birbirlerinden bağımsız bir şekilde geliştirilebilmesi mümkün olur.
Layered System
Sistemdeki bileşenler (components) katmanlarının ötesini göremezler. Client server yapısındaki hangi katmana bağlandığını bilmez. Bu bir ara katman veya son katman olabilir. Böylece, güvenliği veya performansı artırmak için load-balancer’lar (yük dengeleyiciler) ve proxy’ler kullanılabilir.
REST API Design

Ayrıca,

  • Yalnızca URI kullanarak sunucudaki tüm kaynaklara erişmelidir.
  • Dahili şifrelemeye sahip değilidir.
  • Oturum (session) gerektirmemelidir.
  • Tek ve sadece bir HTTP protokolünü kullanmalıdır.
  • CRUD işlemlerini gerçekleştirmek için, get, post, put ve delete gibi HTTP fiillerini kullanmalıdır.
  • Sadece JSON (JavaScript Object Notation), XML, OData gibi (lightweight data) veri formlarını dönmelidir.

Yukarıdaki maddeleri temel aldığımızda, RESTful servislerin yukarıdaki tüm prensiplere uyduğunu, REST temelli servislerin ise bazı prensipleri temel aldığını anlayabiliriz. Örneğin, MVC, yukarıdaki REST prensiplerinin sadece bazılarını desteklerken, WEB API yukarıdaki tüm REST prensiplerini desteklemektedir6 7.

Tüm bu açıklamalar ve prensipleri temel alarak, RESTful servislerin amacının client-server arasındaki veri akışını platform bağımsız olarak gerçekleştirebilmek ve veri akışını en az yükle sağlayabilmek olduğunu söyleyebiliriz.