Rest API nedir ?

 

- REST, İnternet üzerinden bilgisayarlar arasında en yaygın iletişim standardıdır.

- API,Application Programming Interface anlamına gelir. Bu iki bilgisayarın birbiriyle iletişim kurabileceği bir yoldur.

- Çoğu mobil ve web uygulaması tarafından serverlarla iletişime geçmek için kullanılan ortak API standardına REST denir.

- Rest,2000'li yılların başından beri web API oluşturmak için ortak standart olan yeni bir kurallar dizisidir.

Rest ve Restful arasındaki fark nedir?

REST (Representational State Transfer) ve RESTful terimleri genellikle birbirinin yerine kullanılsa da, aralarında hafif bir fark vardır.

REST, web tabanlı uygulamalar arasında kaynaklar üzerinde işlemleri gerçekleştirmek için kullanılan bir mimaridir. REST, kaynaklara benzersiz bir tanımlayıcı (URI) ile erişmeyi ve HTTP protokolünü kullanarak kaynaklarla etkileşimi temsil eder. REST, HTTP metotlarını (GET, POST, PUT, DELETE vb.) kullanarak kaynaklar üzerinde işlemler yapar ve genellikle JSON veya XML formatında veri değişimini tercih eder.

RESTful, REST prensiplerine uygun olarak tasarlanmış ve uygulanan bir web servisi veya API'yi ifade eder. RESTful, REST mimarisinin prensiplerine uygun olarak kaynak odaklı, durumsuz, birleşik arabirim gibi özellikleri barındıran bir web servisidir. RESTful web servisler, HTTP protokolünü temel alır, kaynakları benzersiz URI'larla temsil eder ve standart HTTP metotlarını kullanarak kaynaklar üzerinde işlemler gerçekleştirir. RESTful API'ler genellikle JSON veya XML formatında veri alışverişi yaparlar.

Yani, RESTful, REST prensiplerine uygun olarak tasarlanmış ve uygulanmış bir web servisi veya API'yi ifade ederken, REST, bu prensipleri ve kaynak odaklı mimariyi temsil eder. Terimler genellikle birbirinin yerine kullanılsa da, RESTful terimi daha spesifik bir şekilde REST prensiplerine uygun olan web servislerini ifade eder.

- REST standardını izleyen bir API, RESTful API olarak adlandırılır.

Her HTTP request’inde yapılması istenilen işlemin HTTP Method’larıyla (Verb) ifade edilmelidir.. POST, PUT, DELETE ,GET gibi. Böylece proxy ihtiyacı ortadan kalkmış oluyor ve platform bağımsız yapılar kurmak kolaylaşıyor. 

RESTful servisler’in birçok farklı response tipi olabilir. Bugünlerde popüler olarak JSON kullanılıyor fakat XML, CSV veya amaca bağlı olarak HMTL bile kullanılabilir.

1 — Client Server Architecture

Rest mimarisinin kurallarından birisi Client ve Server bir birinden bağımsız olmalı ve geliştirme sürecinde bu iki bileşen  bir birinden bağımsız olarak geliştirilebilir olmalıdır.

Bu kural sayesinde, birçok client aynı serveri kullanabilecektir çünkü client bazında işlem yapacak şekilde server geliştirmeyeceğiz. 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.

2 — Stateless

REST mimarisinin kullanıldığı web servislerde isteklerin yürütülmesi için gereken tüm bilgiler requestle 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 request 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.

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

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.

[POST] http://base-url/accounts veya [GET] http://base-url/accounts?name=aytac

- 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.

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.

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.

REST vs SOAP

REST’in avantajları nelerdir

- Hafiftir, kolay extend edilebilir.

- Gelen, giden data boyutu SOAP ile karlılaştırıldığında çok ufaktır

- Tasarlaması kolaydır ve implementasyonu kolaydır, herhangi bir ekstra tool’a ihtiyacı yoktur

- HTTP üzerinden çalışır, platform bağımsızdır

SOAP’ın avantajları ;

- Consume etmesi kolaydır, bir şemayla beraber gelir

- Type-safety’dir, sizi bu tür validasyonlarla uğraştırmaz

- Bir sürü development tool’u vardır

- Security implementasyonu REST’e göre daha kolaydır, bir sürü hazır yapı vardır.