REST Mimarisinin 5 Kuralı

You can access the English version via this link.

REST Nedir?

REST (REpresentational State Transfer) “temsili durum geçişi”nin kısaltmasıdır. Web servisler için mimari bir yaklaşımdır. REST mimarine uygun olarak geliştirilmiş servislere de Restful Web Servis ismi verilmektedir.

Photo by Mark Duffel on Unsplash

REST Mimarisindeki Önemli Anahtar Kelimeler

Kaynak (resource)

Domain içerisinde yer alan bilgilerin bir anlam ifade edecek şekilde gruplanmasıyla ortaya çıkan soyut yapılardır. Örneğin; isim, soyisim, doğum tarihi gibi bilgilerin gruplanıp kullanıcı olarak adlandırılmasıyla kullanıcı kaynağı ortaya çıkar. Bir başka örnek ise alıcı, ürünler, fiyat gibi verilerin bir araya gelip gruplanması ile sipariş kaynağını oluşturması olabilir.

Hizmet sağlayıcı (server)

Verileri gruplamaktan sorumlu olan bileşendir. Ayrıca durum geçişlerinde yürütülecek işlemler ve veriler üzerinde yapılabilecek değişimlere dair aksiyonlar hizmet sağlayıcının sorumluluk alanına girer.

Kullanıcı (client)

Kullanıcı anahtar kelimesi insanı çağrıştırmasına karşın arka plan servisleri gibi programlar da kullanıcı olarak nitelendirilmektedir. Bir varlığın kullanıcı olarak nitelendirilmesi için hizmet sağlayıcının sunduğu kaynak üzerinde işlemler yapması yeterlidir.

REST Mimarisinin Kuralları ve Faydaları Nelerdir?

1 — Client Server Architecture

REST mimarisinin kullanıldığı web servis yapılarında iki önemli katılımcı vardır; hizmet sağlayıcı ve kullanıcı. REST mimarisinin kurallarından biri bu iki önemli katılımcının birbirinden bağımsız olmasıdır. Bir diğer deyişle geliştirme sürecinde bu iki bileşen birbirlerinden bağımsız olarak geliştirilebilmelidir.

Bu kural sayesinde, birçok kullanıcı için tek bir hizmet sağlayıcıyı kullanabiliriz çünkü hizmet sağlayıcılarımız kullanıcı bazında işlem yapmayacak şekilde geliştirilmiş olurlar. Ayrıca server tarafında kullanılan programlama dilini veya kullanılan veri saklama ortamlarını değiştirsek de kullanıcı tarafında herhangi bir değişiklik yapmamıza gerek olmayacaktır. Bunun sebebi bu bilgilerin kullanıcı tarafına karşı soyutlanmış olmasıdır. Benzer şekilde kullanıcı tarafında da istediğimiz değişiklikleri yapıp uygulamanın yeni sürümünü kullanmaya başlayabiliriz ve bunun için hizmet sağlayıcı tarafında bir değişiklik yapmamıza gerek olmayacaktır.

2 — Stateless

REST mimarisinin kullanıldığı web servislerde isteklerin yürütülmesi için gereken tüm bilgiler istekle birlikte gelmelidir. Bir isteğin yürütülebilmesi için makina üzerinde daha önce saklanmış verilere ihtiyaç duyulmamalıdır.

Bu kural sayesinde uygulamalarımız yatayda ölçeklenebilir olurlar. Her bir istek işlemin yürütülebilmesi için gereken tüm verilere sahip olduğu için istek, hizmet sağlayıcı tarafından geliştirilmiş uygulamanın kurulu olduğu herhangi bir makinada işlenebilir. Eğer bu kurala uymadan geliştirmelerimizi yaparsak bir isteğin işlenebilmesi için bir makina üzerinde kullanıcıya ait bilgilerin daha önceden saklanması gerekmektedir. Bu durumda da makinalar üzerinde kullanıcı oturumları (session) oluşturmuş oluruz. Binlerce makinadan oluşan bir sistem hayal edelim. Bir makina hariç tüm makinalar işlem yürütmeden bekliyor olsun. Eğer kullanıcıya ait oturum meşgul olan makina üzerinde açılmışsa, kullanıcımız boş makinalardan yararlanamaz ve hizmet almak için bekler. Bu durumda kaynaklarımızı verimli kullanamamış oluruz.

3 — Cacheable

Cache, verinin bir kopyasının kolay erişilebilir bir ortamda saklanması ve verinin asıl kaynağından değil daha hızlı erişilebilinen ortamdan alınması işlemi olarak nitelendirilebilir. Web servisleri kullanıcının isteğini karşılarken verinin cache’lenebilir olup olmadığına dair bilgi dönmelidir. Cache’lenebilir olan veriler içinde bir versiyon numarası kullanıcıya iletilir. Kullanıcının elinde tuttuğu veriye ait versiyon numarası geçerli olduğunu sürece bu bilgi tekrar tekrar kullanılabilir.

Bu kural aracılığıyla kullanıcı ve hizmet sağlayıcı arasında daha az iletişim kurulması amaçlanmaktadır. Hem kullanıcı kaynaklarını daha verimli kullanıyor ve daha hızlı aksiyon alıyor olacaktır hem de hizmet sağlayıcının üzerinde oluşacak yük azalacaktır.

4 — Layered System

Bu kurala göre kullanıcı tarafı ara bir hizmet sağlayıcıyla mı yoksa işlemi yürütecek son katmanla mı iletişimde olduğunu bilmemelidir.

Bu kural aracılığı ile hizmet sağlayıcı ve kullanıcı tarafındaki düşük bağımlılığın var olması gerekliliği bir kez daha vurgulanmıştır. Kullanıcının, bir makina üzerinden hizmet aldığının veya load-balancer gibi araçlarla farklı makinalardan hizmet aldığının farkında olmaması bu kurala uygunluğun sonucudur.

5 — Uniform Interface

Bu kural hizmetin kullanıcıya implementasyon detayı barındırmayacak şekilde sunulması gerektiğini anlatmaktadır.

Bu şekilde farklı mimarilerle ve farklı implementasyonlarla hazırlanmış hizmetler kullanıcıya benzer şekillerde sunulmuş olacaktır. Bu kullanıcı için kolay kullanım imkanı sağlayacaktır. Standartlaştırılmış sunum sayesinde de yazılımcılar arasında ortak bir algılayış olacaktır. Aynı endpointe bakan farklı yazılımcılar — ister prosedürel dille geliştirme yapıyor olsun ister nesne yönelimli bir dille geliştirme yapıyor olsun— aynı anlamı çıkarıyor olacaklardır.

Bu kural 4 alt madde ile betimlenmiştir.

Resource identification in requests

Hizmet sağlayıcıya bir istek iletilirken, hangi kaynak için işlem yürütülmek istendiği bu istek içerisinde belirtilmelidir.

Örnek olarak, hesap (account) kaynağı üzerinde bir işlem yürütmek istediğimizi hayal edelim. [POST] http://base-url/accounts veya [GET] http://base-url/accounts?name=adem gibi endpoint’lerini kullandığımız zaman hesap kaynağı üzerinde işlem yürütme talebimizin olduğunu URI aracılığı ile belirtmiş oluruz.

Resource manipulation through representations

Kullanıcı tarafında kaynağa ait bir veri elde edildiği zaman, kaynak üzerinde gerekli değişiklikleri yapmak için bu veriler yeterli olmalıdır.

Bu kuralı şu şekilde açıklayabiliriz. Ürün olarak temsil edilen veri kümesi üzerinde bir değişiklik yapmak istediğimiz zaman [PATCH] http://base-url/products/PRODUCT_ID endpoint’ini kullanmamız gerektiğini düşünelim.Hangi ürün üzerinde işlem yürütmek istediğimizi PRODUCT_ID verisi ile göstermemiz gereksin. Buna karşın GET eylemi yürüterek ürünler verisini elde ettiğimiz zaman bu veri kümesi içerisinde ürüne ait bir PRODUCT_ID değeri göremediğimizi düşünelim. Bu durumda ürünler kaynağından aldığımız veri, ürünler kaynağı üzerinde bir değişiklik yapmamız için yeterli olmamaktadır. İşte bu durum REST mimarisine uymadığımızı göstermektedir.

Self-descriptive messages

Hizmet sağlayıcıdan alınan cevapların kullanıcı tarafında işlenebilmesi için mesajın kendini anlatan bilgilere sahip olması gerekmektedir.

Bu durumu en güzel açıklayan örneklerden biri Content-Type başlık alanı olabilir. Bu başlık alanına karşılık gelen değer kısmında “application/json”, “text/html” vb. bilgileri görebiliriz. Bu alana baktığımız zaman mesajın nasıl bir parse operasyonundan geçeceğini anlayabilmekteyiz.

Hypermedia as the engine of application state

Kullanıcı aldığı cevaplar içerisinde yer alan linkler aracılığı ile gerekli diğer kaynaklara da erişebilmelidir.

Bir e-ticaret sitesine girdiğimizi düşünelim. 42 id değerine sahip kategori verisini talep etmiş olalım.

[GET] http://base-url/categories/42

Aldığımız kategori cevabının içerisinde bu kategoriye ait ürünlere nasıl ulaşabileceğimize ait bilgiler yer almalıdır.

{
  categoryId: 42,
  categoryName: "office-supplies",
  links:[
      "href": "42/products",
      "rel": "products",
      "type" : "GET"
  ]
}

6 — Code on Demand

Hizmet sağlayıcı kullanıcıya yürütülebilir program parçaları sunabilmelidir.

Hizmet sağlayıcının kullanıcıya javascript gibi yürütülebilir kod parçaları sunabilmesi bu kurala örnek olarak verilebilir.

Bu kural REST için opsiyoneldir. Bu sebeple REST mimarisine uyup uymadığımızı gösteren 5 ana kuraldan bahsedilmektedir.

Umarım yararlı bir yazı olmuştur. Diğer yazılarıma göz atmak için bu linke tıklayabilirsiniz.