RestFul Mimari Nedir
REST client-server iletişimiyle ilgili bir mimari. HTTP protokol’ü ile paralel olarak gelişmiş
olmasının yani sıra bugün en çok hepimizin aşina olduğu World Wide Web sisteminde
kullanılıyor. REST mimarisini kullanan servislere genel olarak RESTful servis deniyor. Ana fikir
aslında client-server arasında ki veri alışverişini SOAP, RPC gibi kompleks mimarilerle sağlamak
yerine, HTTP protokolü üzerinden sağlamak. Çünkü zaten World Wide Web dediğimiz yapı
HTTP protokolü üzerine kurulu. RESTful servisler SOAP, RPC’nin aksine basit ve
hafiftirler.Basit olmalarının yanında oldukça da esnek ve yeteneklidirler. Aslında tipik Web
Servislerle yapabileceğiniz herşeyi RESTful servislerle yapabilirsiniz. Ayrıca mimari olarak nasıl
olması, ne gibi özelliklere sahip olması hakkında belli yönergeler olsa da, burada SOAP gibi
keskin standartları olan bir mimariden bahsetmiyoruz. Üzerine çoğu platformda (C#,JAVA vs.),
bir sürü Framework yazılmış durumda, fakat birçok platformun standart library’leri kullanılarak
kendimiz de hızlıca Restful Servisler geliştirebiliriz. SOAP ile en büyük farkı, SOAP gibi bizi
proxy kullanmaya, bir WSDL’e zorlamıyor olmasıdır.Bunun avantajları ve dezavantajları var
tabiki.REST mimarisindeki önemli noktalardan biride her HTTP request’inde yapılması istenilen
işlemin HTTP Methodlarıyla (Verb) ifade edilmesi. POST,PUT,DELETE,GET gibi, böylece
proxy ihtiyacı ortadan kalkmış oluyor ayrıca platform platform bağımsız yapılara elverişli hale
geliyor. Şuan ki modern uygulamalarda bu Methodları harfiyen kullanmak bir zorunluluk
olmasada, standartlara uymak ve işlem tutartlılığı, güvenliği açısından önemli. 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. İlginç olan önceki yıllardır da
düşük bandwith olmasına rağmen SOAP tabanlı servisler kullanarak kocaman kocaman verileri
XML gibi verinin boyutunu daha da şişiren yöntemlerle aktarıyorduk. Şuan bandwith inanılmaz
boyutlara ulaşmış durumda ve biz veri transferinde, verinin boyutunu XML’e göre inanılmaz
küçülten JSON kullanıyoruz.
Rest Mimari Avantajları ve Kullanan Firmalar
Restful Platform bağımsızlar. (Client’ın Windows, Server’ın Linux olmasının hiç bir önemi yok)
Restful Dil bağımsızdır. Restful HTTP üzerinden çalışır. Restful e snekler ve çok kolay
genişletilebilirdir. Restful servis kullanan büyük firmalar :
-Twitter’ın Rest API’si var
-Google Rest API’si var
-Amazon’un çeşitle amaçlarla kullanılabilecek bir sürü REST servisi var.
-Dünyanın en ünlü oyun firmalarından Blizzard Word of Warcraf oyuncularına karakterleri
-ile ilgili bilgileri RESTful servisler aracılığıyla sunuyor.
– yakında Diablo 3’de benzer bir API gelicek
-Eve Online’ın da benzer bir REST API’si var.
Rest Mimari Kısıtları
Clint-Server Mimarisi : Burada anlatılmak istenilen aslında Separation of Concerns prensibi.
Client’ın Server tarafında ki veri kaynağı hakkında hiç birşey bilmemesi, Server’ın da doğru
istekler geldiği sürece doğru yanıtı vermesi. Client ile Server’ın birbirlerinden bağımsız olması .
Amaç aslında platform bağımsız çalışmayı ve scalability’i arttırmak. Ayrıca aralarında ki interface
ortak kaldığı sürece birbirlerinden bağımsız bir şekilde gelişmeleri de sağlanmış oluyor.
Stateless : Server tarafında, client ile ilgili bir context veya Session tutulmaz. Client tarafından
yapılan her request Server’ın response verebilmesi için gerekli bilgiyi taşır, yani her türlü state
client tarafında tutulur, ihtiyaç duyulursa request içerisinde server’a bildirilir.
BuScalability açısından da önemlidir, çünkü server’ın requestler arasında herhangi bir state’i
saklamasını gereksiz kılar ve kaynak yönetimini kolaylaştırır. Visibility açısından önemlidir,
çünkü request’in amacını anlamak için tek bir request’in içerdiği bilgiler yeterlidir.
Tabi stateless olmasının bazı dezavantajlarıda var. Client her request’de gerekli bilgileri eklemek
zorundadır bu da network trafiğini arttırır. Bu ayrıca server’ın uygulamanın davranışlarındaki
tutarlığı kontrol etmesini zorlaştırır, çünkü birçok farklı client’dan farklı içerikli requestler
gelebilir, server’a validasyon açısından daha fazla yük binebilir.
Cacheable : HTTP response’ları client tarafından “cache”lenebilir, o yüzden Server gönderdiği
response’ların cacheable olup olmadığını belirtmek durumundadır, bu performans açısından
önemlidir.
Uniform Interface : Client-Server’lar arasında Ortak, tekbiçimli arayüzlerin olması REST’in en
önemli prensiplerinden biridir. Bu hem iletişim yöntemini basitleştiriyor hem de ortak bir
interface olması sayesinde her parçanın birbirinden bağımsız bir şekilde evrimleşmesine olanak
sağlıyor. Bu konu daha önce bahsettiğim HTTP Methodları ilede alakalı.
HTTP Method’ları ve REST’de Kullanımı
Matematik ve bilgisayar biliminde bir fonksiyonun bir defa uygulanması ile birden fazla defa
uygulanması, sonucu değiştirmiyor ise bu fonksiyon Idempotent’dir. HTTP methodları arasında
GET, PUT, DELETE Idempotent methodlardır. POST değildir. Bugün aslında GET ve POST her
işimizi görüyor. Peki neden POST yerine PUT ve ya silmek için ayriyetten DELETE
methodlarına da kullanmamız gerekiyor. Bunun birkaç sebebi olmasına rağmen bu sebeplerin hiç
biri bizi PUT ve DELETE kullanmak zorunda bırakan sebepler değil. Ama REST’in tek amacı
data’ya en basit şekilde ulaşmak değildir, REST aynı zamanda data’ya anlamlı bir şekilde ulaşma
metadolojisidir, bir request’e baktığınız zaman onun ne iş yaptığını anlamanız önemlidir. Ayrıca
idempotency kavramıda bu noktada önemli. Akla ilk gelicek sorulardan biri POST mu? PUT mu?
PUT ve POST arasındaki kavramsal farktan daha öncede bahsettik, PUT idempotent bir method,
yani aynı Resource’a yaptığınız aynı PUT request’ini bir veya birden fazla defa yapmanız sonuç
açısından birşey fark etmez, fakat POST aynı şey değil, o yüzden browserlar bizi POST yapılan
bir yerde refresh, back gibi şeyler yaptığımızda uyarır, çünkü server’da ilgili resource’un state’i
değişebilir. Tamam uygulamayı biz yazıyoruz, requestleri karşılayan bizleriz, POST’un da aynı
davranışını sergilmesini sağlayabiliriz fakat client açısından mesela browserlar açısından PUT ve
POST arasında çok fark var. Uniform Interface kısıtında da aslında kast edilen bu.
Demek istediğim create işlemlerinde PUT kullanın değil, kafanız karışmasın, tam anlamıyla
gerektiği yerde kullanmak lazım.
“ HTTP/1.1 PUT /DataStorage/Pictures/mesut.jpg
<mesut.jpg’in içeriği … >”
Yukarıda bir request ile mesut.jpg adında bir resource’u server’da yaratıyoruz, bu request’i 100
kere de göndersek fark etmez çünkü hep mesut.jpg’yi gönderiyoruz. Bütün content’i aynı spesifik
bir Resource’a gönderiyoruz. Fakat ;
“
HTTP/1.1 POST /DataStorage/Pictures
…
<?xml version=”1.0″ encoding=”UTF-8″?>
<DataStorage operation=”add” type=”jpeg”>
<[CDATA[ <herhangi bir resmin içeriği > ]]>
</DataStorage> “
Eğer bu request’i birden fazla tekrarlarsak, aynı content’e sahip 2 adet resim server tarafında
oluşur. POST’un gücü ve tehlikesi de bu, POST ile herşeyi yapabilirsiniz, Create,Delete,Update
herşeyi. Örnek ile bakarsak bir forum siteniz var ve bir başlığın altına yorum eklemek istiyoruz,
ilgili alanları doldurduktan sonra POST ederiz, çünkü bu aşamada bize PUT’daki gibi HTTP 200
(No error, operation successful.) response’u yetmez, çünkü aynı zamanda bir resource’da
değişiklik yapıyoruz ve yaptığımız değişikliği görmek isteriz, o yüzden ASP.NET’de Postback
kavramı vardır.
Aslında özet ile bakarsak ;
•Create = Eğer spesifik bir Resource’un bütün bir içeriğini gönderiliyorsa PUT kullanılır.
•Create = Eğer server’a spesifik bir Resource’a bağlı olan içerik gönderiliyorsa POST
kullanılır.
•Retrieve = GET.
•Update = Eğer spesifik bir Resource’un bütün bir içeriğini gönderiliyorsa PUT kullanılır.
•Update = Eğer spesifik bir Resource’a bağlı bir veya birden fazla içerik değiştiriliyorsa
POST kullanılır.
•DELETE = Silme işlemi yapar.
Rest Mimaride Güvenlik
REST, SAOP veya RPC’de ki gibi hazır bir security yapısıyla gelmiyor, aslında bir security
yapısıda diretmiyor. Yine de kullanabileceğiniz bir çok yöntem söz konusu. REST’in HTTP
protokolünü kullandığından bahsetmiştik, HTTP’nin de kendine has Authentication
mekanizmaları var, bunları kullanmamız açısından hiç bir engel yok. Bunlardan en popüleri Basic
Access Authentication. Kullanması çok kolay, fakat kesinlikle HTTPS ile beraber kullanılması
gerekiyor, çünkü şifreyi plain-text olarak gönderiyor, HTTPS ile kullandığımız zaman encrypted
olarak gönderebiliyoruz.
Diğer alternatifimiz ise Digest Authentication, bu da HTTP’nin Authentication
mekanizmalarından birisi. Bu mimaride şifre plain-text olarak gönderilmek yerine, data’nın o
şifre ile hash’i alınır öyle gönderilir. Server gelen datanın hash’ini aynı şifre tekrar alır ve hashleri
karşılaştırır böylece datanın valid bir yerden gelip gelmedğini anlar. Tabi buradaki en önemli
nokta client ile server’ın şifreyi bilmesi gerekliliği ki server’da aynı şifre ile hash alıp
karşılaştırma yapılabilir.Olaylar şu şekilde gelişiyor, client server’a bir request’de bulunuyor ve server 401
(“Unauthorized”)
response’unu döndürür. Client bu cevabı aldıktan sonra bunun Authorization gerektiren bir request olduğunu anlar ve request’in Header’ına Authorization datasını ekler (Hash’li data), server bu sefer istenilen yanıtı verir. Basic Access Authentication’dan daha güvenli bir yöntem olsa da hala brute force gibi saldırılara açıktır ayrıca bütün server ve
browser’lar tarafından desteklenmemektedir. Tabi tek seçeneğimiz HTTP’nin bize sağladığı güvenlik mekanizmaları değil hata günümüzde çoğunlukla RESTful servislerde HMAC (Hash Message Authentication Code) yöntemini
kullanılıyor. Aslında bu costum bir yapı, digest’deki gibi “Authorization” header üzerinden
security bilgilerini yolluyoruz. Olay şu ; Server client’a bir şekilde userId ve secret key sağlıyor. Nasıl sağladığının hiç bir önemi yok, bu konuyu araştırken en çok bu noktaya takılmıştım, siz takılmayın. Yani adam bir şekilde bir yere
user id ile kayıt olur oradan alır veya email ile kendisine gelir veya normal postayla . Önemli olan
Server’ın Client’a bu bilgiyi sağlamış olması ve kendi tarafında user ile ilişkili olarak bu key’i
tutuyor olması. Client bu aşamadan sonra bütün requestlerini bu userid ve key ile imzalayıp öyle gönderirir.
Burada dikkat edilmesi gereken nokta Server’ın Client’a request’in hangi kısımınlarını, hangi
algoritma ile imzalayacağını bildirmesi gerekliliği. Çünkü client her request’de kendisine verilen
algoritmayla HMAC Hash’ini üretip, userid’si ile beraber “Authorization” header’ına eklemeli.
Authorization: dirgin:uBMfGaLjue+TSDygYB5aEg==
Server request’i aldıktan sonra “Authorization” header’ı alıp split eder ve gelen userid’nin kendi
tarafında kayıtlı olan key’ini bulur, ardından request’deki ilgili alanların HMAC Hash’ini bu key
ile tekrar alır ve kendisine gelen Hash ile karşılaştırır. Eğer hash’ler aynıysa kullanıcının yetkili
bir kullanıcı olduğu anlaşılıp doğru response dönülür.
HMAC yaklaşımı Basic Access Authentication ve Digest Authentication’a göre daha etkili bir
yaklaşım verilen key random ve yeterince uzunsa brute force saldırılarına karşıda etkili.
Ayrıca paranoyak olmanızı gerektiren bir durum varsa kullanıclara verilen keylerin belli bir süre
sonra expire olmasını sağlayabilirsiniz böylece kullanıcı belli aralıklarla yeniden bir key edinmek
durumunda kalır. Bu yaklaşım RESTful servislerde en çok kullanılan yaklaşım.