REST(Representational State Transfer)
Bu yazıda iki temel web servis mimarisinden biri olan ve public API ların % 70 inde kullanılan REST’i anlatmaya çalışacağım.
HTTP protokolünün geliştiricilerinden biri olan Roy Fielding’in doktora tezi ile bilişim dünyası REST kavramıyla tanıştı.Tezde, web servisler için geliştirilmiş mimari stil olarak tanımlanan REST altı temel özellik bulundurmaktadır. REST mimarisi ile yazılan her servis ve API bu altı özelliği taşımalıdır.
1. Client-Server(istemci-sunucu)
Sunucular ve istemciler arasında kesin ve açık bir ayrım olmalıdır.
2. Stateless(~taşınmazlık)
Bir istemci request(istek)i , onu yürütmek için gerekli olan tüm bilgileri içermelidir. Sunucu, bir istekte bulunan istemciyle ilgili herhangi bir durumu başka bir istemciye kaydetmemelidir.
3. Cache(önbellek)
Sunucudan gelen response(yanıt)lar önbelleğe alınabilir ya da saklanmaz olarak etiketlenebilir. Böylece istemciler (veya istemci ile sunucular arasındaki aracılar) optimizasyon amacıyla belleği istedikleri gibi kullanabilirler.
4. Uniform Interface(standart arayüz)
İstemcilerin sunucunun kaynaklarına erişme protokolü tutarlı, iyi tanımlanmış ve standartlaştırılmış olmalıdır. REST web servisleri için en yaygın kullanılan uniform interface HTTP (Hyper Text Transfer Protocol) protokolüdür.
5. Layered System(katmanlı sistem)
Performans, güvenilirlik ve ölçeklenebilirliği geliştirmek için istemciler ve sunucular arasına proxy sunucuları, önbellekler ya da ağ geçitleri(gateway) eklenebilir. Proxy nin ne olduğuna kısaca değinecek olursak…

Proxy, internet üzerindeki bir bilgisayar ile internete bağlı diğer bilgisayarlar arasındaki iletişimi sağlayan yardımcı bir geçiş yolu (gateway) sistemidir. Bir proxy sunucusu sizden aldığı istekleri yürütür ve sonucu yine size iletir. Ayrıca bu bilgiler proxy sunucusu üzerinde (cache te) tutulur ve daha sonraki isteklerde bilgiler doğrudan ilgili siteden değil , proxy servisinden gelir. Böylece daha hızlı erişim sağlamış oluruz.
Proxy internette iz bırakmamak için de kullanılır. Kelime anlamı olarak proxy vekil demektir. Yani sizin vekiliniz olarak sitelerle iletişime geçer. Bu sayede bir siteye girdiğinizde sizin girdiğiniz bilinmez, görünmez olursunuz.
6. Code-on-Demand(isteğe bağlı kodlayabilme)
İstemciler kendi ortamlarında çalıştırmak için isteğe bağlı olarak sunucudan kod indirebilirler.
REST in temelindeki altı madde böyleydi. Şimdi REST in asıl konseptine geçelim.
REST mimari stilinin çekirdeği resources yani kaynaklardır. Resources (kaynaklar) kavramını açacak olursak, uygulama alanıyla(application domain) ilgili her item (ona bağlı olan bütün bilgilerle birlikte) bir kaynaktır. Örneğin bir blog uygulamasında kullanıcılar, yorumlar ve postların hepsi birer kaynaktır.
Her kaynağın sadece ona ait bir URL adresi olmalıdır. Blog örneğinden devam edeceksek URL/api/comments/12345 adresindeki 12345 yorumların tutulduğu veritabanında ilgili yorum için bir primary key(birincil anahtar)dır.
Ayrıca her kaynağın diğer kaynaklarla arasında bağlantılar ve metodlar bulunur. Bu bağlantı ve metodlar sayesinde bir kaynak koleksiyonuna sahipseniz bu kaynaklarla bağlantılı birden fazla kaynak ya da kaynak koleksiyonuna erişim sağlayabilirsiniz.
Request Methods
İstemci uygulaması (client app), kaynak URLlerinde sunucuya istek gönderir ve istenen işlemi belirtmek için http metodlarını kullanır. REST mimarisi basit bir konsepte sahiptir, HTTP nin bütün metodlarını kullanmayı gerektirmez. REST mimarisindeki http metodları GET, POST, PUT ve DELETE dir. Yalnızca bu dört metodu kullanarak REST, dil özellikleri, eklentiler gibi detaylara takılmadan, ilgili verinin elementlerine ve elemanların oynadığı rollere odaklanır. Özetle bahsedecek olursak HTTP nin en temel dört komutu şunlardır:

- GET : Bir kaynaktan(resource) veri istemek için kullanılır. GET ile kaynaktaki veriyi değiştirmek mümkün değildir.
- POST : Yeni bir kaynak oluşturmak veya mevcut kaynağı değiştirmek için kullanılır. POST methodunda veri, metodun gövdesinde iletilir.
- PUT : POST metodu gibi create/update işlemi yapar. Aralarındaki önemli fark; create operasyonu için birden fazla PUT request yapılsa da tek ve aynı sonuç elde edilir. PUT metodu eski kaynağın üstüne yenisini yazar. Ancak birden fazla POST request yapılırsa aynı kaynak birden fazla sayıda oluşturulmuş olur.
- DELETE : Mevcut kaynağı silmek için kullanılır.
Blog örneğinde istemci mevcut yorumların bir listesini almak için https://www.example.com/api/comments adresine GET ile bir istek yapar. Yeni bir yorum yazıldığında bunu veritabanına kaydetmek için aynı URL adresine POST request yapar (yapılan yorumla ilgili içerik metodun gövdesinde iletilir)
HTTP ile ilgili detaylı bilgiye link ten ulaşabilirsiniz. Mozilla’nın dokümanına da göz atabilirsiniz.
Request(istek) ve Response(yanıt) Gövdeleri
Kaynaklarla ilgili içeriğin, sunucu ve istemci arasında request ve responseların gövdelerinde taşındığından bahsetmiştik. Nasıl taşındığı sorusuna gelecek olursak REST in bu konuda belirlediği standart bir format yoktur. Kaynağın request-response gövdesinde kodlandığı biçim, Content-Type(içerik türü) başlığında belirtilir.İstemci ve sunucu arasında ortak bir format kullanılması için HTTP protokolündeki standart içerik anlaşması mekanizmaları kullanılabilir. REST tabanlı web servislerinin kullandığı en popüler formatlar Java Script Obect Notation(JSON) ve Extensible Markup Language(XML) dir.
Blog uygulaması örneğinden devam edecek olursak bir blog postunun JSON ile temsili aşağıdaki gibidir.
{
“url”: “http://www.example.com/api/posts/12345",
“title”: “Writing RESTful APIs in Python”,
“author”: “http://www.example.com/api/users/2",
“body”: “… text of the article here …”,
“comments”: “http://www.example.com/api/posts/12345/comments"
}Aynı blog postu kaynağının XML ile temsili ise aşağıdaki gibi olacaktır.
<?xml version=”1.0" encoding=”UTF-8" ?>
<root>
<url>http://www.example.com/api/posts/12345</url>
<title>Writing RESTful APIs in Python</title>
<author>http://www.example.com/api/users/2</author>
<body>… text of the article here …</body>
<comments>http://www.example.com/api/posts/12345/comments</comments>
</root>Yazım stilllerinden de anlayacağınız üzere JSON JavaScript’e , XML HTML’e çok yakındır. Aklınıza peki hangisini kullanmalıyım gibi bir soru gelebilir, gelişmiş web uygulamaları için JSON, web tarayıcıları tarafından kullanılan JavaScript’e yakınlığıyla tercih sebebi olacaktır.
Örneklerde url, author ve comments alanlarının tam nitelikli URL ler olarak tanımlandığını farketmişsinizdir. Bu tanımlamalar önemli çünkü iyi tasarlanmış RESTful API larda istemci sadece en önemli kaynak URLlerini bilir, geri kalan bilgiyi response gövdesindeki bu URLlerden keşfeder. Tıpkı internette gezerken bir sayfadaki link sayesinde diğer sayfalara ulaşabilmemiz gibi.
REST vs SOAP
Konu web servisler ve API yazmak olunca akla gelen en temel, belki de en önemli konu SOAP mı REST mi tercih edilmeli ? Aralarındaki fark nedir, avantajları-dezavantajları…

REST hakkında bildiklerim ve anlatacaklarım bunlardı. Eksik veya yanlış buldugunuz bir şey olursa yazın lutfen. Python-Flask ile RESTful API yazmakla ilgili yazılarla gorusmek uzere.
Kaynaklar
- Flask Web Development - Miguel Grinberg / Chapter 14
- developer.mozilla.org
- https://www.soapui.org/resources/infographic/api-testing/soap-vs-rest-infographic.html