Herhangi bir modern platform i\u00e7in kod yazd\u0131ysan\u0131z, kesinlikle bir web API ile etkile\u015fime girmi\u015fsinizdir. \u00c7o\u011fu zaman bu API muhtemelen REST’tir. Uzun s\u00fcredir programlama yap\u0131yorsan\u0131z veya biraz daha eski bir sistem kulland\u0131ysan\u0131z, bu API SOAP bile olabilir. Ancak son zamanlarda GraphQL hakk\u0131nda da olduk\u00e7a fazla konu\u015fulmaktad\u0131r.<\/p>\n\n\n\n
Peki GraphQL ve REST API nedir ve bu iki API t\u00fcr\u00fc aras\u0131ndaki farklar nelerdir?<\/p>\n\n\n\n
REST, “Representational State Transfer” anlam\u0131na gelir. Bir API’nin nas\u0131l g\u00f6r\u00fcnece\u011fini belirleyen bir dizi kurald\u0131r. Bu kurallardan biri, belirli bir URL’ye ba\u011fland\u0131\u011f\u0131n\u0131zda bir kaynak (bir veri par\u00e7as\u0131) alman\u0131z gerekti\u011fini belirtir.<\/p>\n\n\n\n
URL’ye istek, geri g\u00f6nderilen veriye de yan\u0131t denir.<\/p>\n\n\n\n
Bir RESTful API’yi \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131zda, sunucu kayna\u011f\u0131n durumunun temsilini istemciye aktar\u0131r.<\/p>\n\n\n\n
\u00d6rne\u011fin, belirli bir kullan\u0131c\u0131y\u0131 almak i\u00e7in Facebook Profil API’sini \u00e7a\u011f\u0131r\u0131rsan\u0131z REST, ad, profil resmi, son g\u00f6nderiler ve daha fazlas\u0131 dahil olmak \u00fczere bu kullan\u0131c\u0131n\u0131n durumunu aktar\u0131r.<\/p>\n\n\n\n
REST’te bir i\u015flem ger\u00e7ekle\u015ftirmek i\u00e7in bu i\u015flemi GET, POST, PUT veya DELETE gibi bir HTTP iste\u011fi \u015feklinde \u00e7a\u011f\u0131rman\u0131z gerekir. \u00d6rne\u011fin, belirli bir kullan\u0131c\u0131n\u0131n Facebook profilini almak i\u00e7in o kullan\u0131c\u0131y\u0131 tan\u0131mlayan URL’ye ve HTTP y\u00f6ntemi GET’e ihtiyac\u0131n\u0131z olacakt\u0131r.<\/p>\n\n\n\n
REST API’lerinin ana fikirleri a\u015fa\u011f\u0131dakileri i\u00e7erir:<\/p>\n\n\n\n
REST, temel olarak API’deki herhangi bir varl\u0131k anlam\u0131na gelen bir “kaynak” kavram\u0131na sahiptir. Genel olarak, bir kaynak i\u00e7in bir u\u00e7 noktas\u0131 vard\u0131r.<\/p>\n\n\n\n
\u00d6rne\u011fin GitHub’\u0131n REST API’sini ele alal\u0131m:<\/p>\n\n\n\n
Bir kullan\u0131c\u0131 bir “kaynakt\u0131r”. Bu kaynakla https:\/\/api.github.com\/users\/{username} adresine bir GET iste\u011fi g\u00f6ndererek etkile\u015fime ge\u00e7ebiliriz. {username} yerine ilgilendi\u011fimiz kullan\u0131c\u0131n\u0131n ger\u00e7ek kullan\u0131c\u0131 ad\u0131n\u0131 yazman\u0131z gerekir. Bu bir kullan\u0131c\u0131n\u0131n bilgilerini alman\u0131n ba\u015fka bir yolu yoktur.<\/p>\n\n\n\n
Benzer \u015fekilde, bir depo da bir “kaynakt\u0131r”. Belirli bir depo hakk\u0131nda bilgi almak i\u00e7in https:\/\/api.github.com\/repos\/{owner}\/{repo} adresine bir GET iste\u011fi g\u00f6ndererek {owner} ve {repo} de\u011ferlerini ilgili de\u011ferlerle de\u011fi\u015ftirebilirsiniz.<\/p>\n\n\n\n
REST’ten \u00f6nce, SOAP (Simple Object Access Protocol) \u015firketlerin b\u00fcy\u00fck bir k\u0131sm\u0131 taraf\u0131ndan API’ler olu\u015fturmak i\u00e7in kullan\u0131l\u0131yordu. Her ikisinin de arkas\u0131ndaki motivasyon benzerdi: platformlar aras\u0131nda kolay veri al\u0131\u015fveri\u015fi sa\u011flamak. Fakat REST \u00e7e\u015fitli veri formatlar\u0131na izin verirken, SOAP yaln\u0131zca XML ile \u00e7al\u0131\u015f\u0131r. <\/p>\n\n\n\n
Burada dikkat edilmesi gereken \u00f6nemli bir nokta, SOAP’\u0131n bir protokol, REST’in ise bir mimari model oldu\u011fudur. “REST API” dedi\u011fimizde, asl\u0131nda REST mimarisini takip eden web hizmetleri i\u00e7in do\u011fru terim olan “RESTful API” demek istiyoruz.<\/p>\n\n\n\n
2000’li y\u0131llar\u0131n ba\u015f\u0131nda Roy Fielding liderli\u011findeki bir grup, veri al\u0131\u015fveri\u015fi i\u00e7in daha iyi bir yap\u0131 elde etmek amac\u0131yla REST mimarisini olu\u015fturdu. REST API’leri, daha y\u00fcksek uyumluluklar\u0131, durumsuz mimarileri ve daha iyi \u00f6nbellekleme mekanizmalar\u0131 nedeniyle SOAP API’lerine kar\u015f\u0131 etkili bir \u015fekilde kazand\u0131.<\/p>\n\n\n\n
Yeni ba\u015flayanlar i\u00e7in, RESTful API’ler ihtiya\u00e7 duyulandan daha fazla veri d\u00f6nd\u00fcr\u00fcyordu, bu da daha fazla API \u00e7a\u011fr\u0131s\u0131 anlam\u0131na geliyordu. Her u\u00e7 nokta yaln\u0131zca belirtilen verileri d\u00f6nd\u00fcrebildi\u011finden, geli\u015ftiriciler u\u00e7 noktalar\u0131 \u00f6n u\u00e7 g\u00f6r\u00fcn\u00fcmlerini ak\u0131lda tutarak tasarlamak zorundayd\u0131.<\/p>\n\n\n\n
T\u00fcm bunlar daha az esneklikle sonu\u00e7land\u0131 ve Facebook m\u00fchendisleri REST’e bir alternatif olu\u015fturmaya karar verdi. GraphQL, 2012 y\u0131l\u0131nda Facebook taraf\u0131ndan olu\u015fturuldu ve 2015 y\u0131l\u0131nda a\u00e7\u0131k kaynak haline getirildi.<\/p>\n\n\n\n
GraphQL, bir sunucu ile nas\u0131l ileti\u015fim kurabilece\u011finizi ve bir istemciden bir sunucuya nas\u0131l veri aktarabilece\u011finizi a\u00e7\u0131klar. GraphQL, istemcinin hangi verilere ihtiya\u00e7 duydu\u011funu \u00f6zellikle sorabilmesi nedeniyle REST’ten temel olarak farkl\u0131d\u0131r.<\/p>\n\n\n\n
GraphQL, birden fazla kaynaktan veri almay\u0131 ve toplamay\u0131 kolayla\u015ft\u0131r\u0131r. Birden fazla u\u00e7 nokta yerine, karma\u015f\u0131k sorgular\u0131 toplayabilen ve \u00e7\u0131kt\u0131y\u0131 istemcinin istedi\u011fi formatta sunabilen “ak\u0131ll\u0131” bir u\u00e7 noktan\u0131z vard\u0131.<\/p>\n\n\n\n
\u00d6rne\u011fin, kafenizden yemek sipari\u015f etmeniz, marketten al\u0131\u015fveri\u015f yapman\u0131z ve bir k\u00fct\u00fcphaneden kitap \u00f6d\u00fcn\u00e7 alman\u0131z gerekti\u011fini d\u00fc\u015f\u00fcn\u00fcn. REST ile, \u00fc\u00e7 istek olan \u00fc\u00e7 farkl\u0131 telefon g\u00f6r\u00fc\u015fmesi yapars\u0131n\u0131z.<\/p>\n\n\n\n
GraphQL ile bu \u00fc\u00e7 telefon g\u00f6r\u00fc\u015fmesi, Siri ile konu\u015fmak gibi tek bir g\u00f6r\u00fc\u015fme ile de\u011fi\u015ftirilebilir. Tek yapman\u0131z gereken bu yerlerin adresini s\u00f6ylemek ve ard\u0131ndan sipari\u015finizi vermek.<\/p>\n\n\n\n
Ba\u015flang\u0131\u00e7ta \u015firket, Facebook uygulamas\u0131n\u0131 geli\u015ftirirken b\u00fcy\u00fck \u00f6l\u00e7\u00fcde web teknolojilerinden yararlanm\u0131\u015ft\u0131. Ancak, \u015firket nihayet yerel bir mobil uygulama olu\u015fturmaya karar verdi\u011finde, normal API’ler uygulaman\u0131n baz\u0131 y\u00f6nlerini olu\u015fturmak i\u00e7in verimli bir yol sa\u011flayamad\u0131. \u00d6rnek olarak, g\u00f6nderinin kendisi, be\u011fenen, yorum yapan, payla\u015fan ki\u015filer ve \u00e7ok daha fazlas\u0131 gibi \u00e7e\u015fitli verileri alan haber ak\u0131\u015f\u0131 deneyiminin optimizasyona ihtiyac\u0131 vard\u0131. G\u00f6nderiler birbirine ba\u011fl\u0131 oldu\u011fundan, basit bir hiyerar\u015fik veri yap\u0131s\u0131yla \u00e7al\u0131\u015fmak zordu; bu nedenle verileri yap\u0131land\u0131rmak ve sorgulamak i\u00e7in yeni bir yol olu\u015fturmalar\u0131 gerekiyordu. GraphQL ilk olarak Facebook’ta Lee Byron taraf\u0131ndan geli\u015ftirildi ve 2015 y\u0131l\u0131nda halka a\u00e7\u0131ld\u0131. \u015eu anda Linux vakf\u0131 taraf\u0131ndan bar\u0131nd\u0131r\u0131lmaktad\u0131r. <\/p>\n\n\n\n
Her bir yakla\u015f\u0131ma en iyi uyan baz\u0131 kullan\u0131m durumlar\u0131 a\u015fa\u011f\u0131daki \u015fekildedir:<\/p>\n\n\n\n
GraphQL ve REST temelde ayn\u0131 g\u00f6revi yerine getirir: bir sunucu ile ileti\u015fim kurmak ve veri almak. Fakat ikisi aras\u0131ndaki birka\u00e7 benzerlik vard\u0131r.<\/p>\n\n\n\n
\u00c7o\u011fu REST API’sinin di\u011ferlerinden biraz farkl\u0131 uygulanabilece\u011fini bilmek \u00f6nemlidir ve bu genel bir kar\u015f\u0131la\u015ft\u0131rma olsa da, baz\u0131 REST API’leri di\u011ferlerinden daha y\u00fcksek kullan\u0131labilirli\u011fe sahip olabilir. REST bir mimari oldu\u011fundan, baz\u0131 iyi uygulanm\u0131\u015f API’lerin yan\u0131 s\u0131ra uygun u\u00e7 noktalar\u0131 belirtmeyen veya versiyonlamay\u0131 k\u00f6t\u00fc uygulayan daha da\u011f\u0131n\u0131k API’ler de olabilir.\u00a0<\/p>\n\n\n\n
Veri a\u00e7\u0131s\u0131ndan, GraphQL geli\u015ftiriciye yaln\u0131zca belirttiklerini verir ve daha fazlas\u0131n\u0131 vermezken, REST, u\u00e7 noktadan istenen yap\u0131land\u0131r\u0131lm\u0131\u015f verilerde mevcutsa, hemen hemen her \u015feyi verir. Verilerin tamam\u0131n\u0131 almak i\u00e7in genellikle birden fazla \u00e7a\u011fr\u0131 gerekmedi\u011finden, bu durum GraphQL ile istemci taraf\u0131nda \u00e7al\u0131\u015fmay\u0131 kolayla\u015ft\u0131rsa da, bunun \u00f6nemli bir dezavantaj\u0131, veri talep ederken istemcide daha fazla spesifikasyonun gerekli olmas\u0131 ve gerekli t\u00fcm sorgular\u0131 i\u015flemek i\u00e7in API taraf\u0131nda daha fazla kurulum gerekmesidir. Bu ayn\u0131 zamanda, API’nin kendisi i\u00e7in m\u00fcmk\u00fcn olan sorgular\u0131, mutasyonlar\u0131 ve potansiyel bir sorgudan talep edilebilecek verileri belirtmek i\u00e7in arka u\u00e7ta baz\u0131 ekstra ad\u0131mlar gerektirir. Ayr\u0131ca, istemci taraf\u0131nda, her sorgu i\u00e7in gerekli alanlar\u0131 belirtmek i\u00e7in ekstra \u00e7al\u0131\u015fma vard\u0131r.<\/p>\n\n\n\n
Kullan\u0131labilirlik a\u00e7\u0131s\u0131ndan ba\u015fka endi\u015feler de vard\u0131r: \u00c7o\u011fu RESTful API sa\u011flay\u0131c\u0131s\u0131, sahip olduklar\u0131 her u\u00e7 nokta i\u00e7in h\u0131z s\u0131n\u0131rlar\u0131 sa\u011flar ve bu da hi\u00e7bir API u\u00e7 noktas\u0131n\u0131n \u00e7ok s\u0131k \u00e7a\u011fr\u0131lmamas\u0131n\u0131 garanti eder. Ayr\u0131ca uygun bir \u015fekilde \u00fccretlendirebilir veya geli\u015ftiricinin istedi\u011fini almas\u0131n\u0131 kolayla\u015ft\u0131ran belirli planlar sa\u011flayabilirler. GraphQL istemci taraf\u0131nda genel sorgulara sahip oldu\u011fundan, bu durum arka u\u00e7ta \u00e7\u00f6z\u00fcl\u00fcr ve h\u0131z s\u0131n\u0131rlar\u0131n\u0131n uygulanmas\u0131 zorla\u015f\u0131r.\u00a0<\/p>\n\n\n\n
\u0130stemci genel olarak ayr\u0131lm\u0131\u015f verilere ihtiya\u00e7 duyuyorsa (bir kitap listesi, bir nesnenin ayr\u0131nt\u0131l\u0131 g\u00f6r\u00fcn\u00fcm\u00fc, vb.), REST olduk\u00e7a iyi sonu\u00e7 verir ve uygulanmas\u0131 \u00e7ok daha kolayd\u0131r. Veriler makul boyutlarda oldu\u011funda, b\u00fcy\u00fck k\u00fcmeler i\u00e7in sayfaland\u0131rma uyguland\u0131\u011f\u0131nda ve veri almak i\u00e7in birden fazla \u00e7a\u011fr\u0131 gerekmedi\u011finde, REST yakla\u015f\u0131m\u0131n\u0131 benimsemek bir \u015firket i\u00e7in geli\u015ftirme s\u00fcrecinde zaman ve para tasarrufu sa\u011flayabilir. <\/p>\n\n\n\n
\u0130stemci taraf\u0131 uygulamas\u0131, \u00e7ok say\u0131da REST \u00e7a\u011fr\u0131s\u0131 gerektirebilecek birbirine ba\u011fl\u0131 birka\u00e7 \u00f6\u011fe i\u00e7eriyorsa, GraphQL muhtemelen iyi bir se\u00e7enek olacakt\u0131r ve zaman i\u00e7inde daha verimli olaca\u011f\u0131ndan uygulamaya zaman ay\u0131rmaya de\u011ferdir.<\/p>\n\n\n\n
REST’in mi yoksa GraphQL’in mi daha iyi performans verdi\u011fine karar vermeyi sa\u011flayan ana fakt\u00f6rler, getirilen veri t\u00fcrleri ve bunlar\u0131n ne s\u0131kl\u0131kta getirilmesi gerekti\u011fidir. <\/p>\n\n\n\n
GraphQL yaln\u0131zca gerekli verileri sa\u011flad\u0131\u011f\u0131ndan (muhtemelen birden fazla veri t\u00fcr\u00fcnden getirme), daha az veri sa\u011flayabilir ve yaln\u0131zca gerekli verileri sa\u011flamas\u0131 gerekti\u011finden \u00e7a\u011fr\u0131y\u0131 tamamlamak daha az zaman alabilir.<\/p>\n\n\n\n
\u00d6te yandan REST, API \u00e7a\u011fr\u0131lar\u0131n\u0131n do\u011fas\u0131 gere\u011fi daha yava\u015f olmas\u0131 nedeniyle de\u011fil, istemci taraf\u0131nda bir i\u015flemi tam olarak tamamlamak ve kullan\u0131c\u0131n\u0131n ne talep etti\u011fine bak\u0131lmaks\u0131z\u0131n t\u00fcm veri setini sa\u011flamak i\u00e7in birden fazla \u00e7a\u011fr\u0131n\u0131n y\u00fcr\u00fct\u00fclmesi gerekebilece\u011finden daha fazla zaman alabilir. \u0130ki farkl\u0131 nesne t\u00fcr\u00fcn\u00fcn getirilmesi gerekiyorsa, iki farkl\u0131 REST \u00e7a\u011fr\u0131s\u0131 s\u00f6z konusu olacak ve bu da getirme s\u00fcrelerinin artmas\u0131na neden olacakt\u0131r. <\/p>\n\n\n\n
Ancak REST’in \u00fcst\u00fcnl\u00fck sa\u011flad\u0131\u011f\u0131 nokta, tekrarlanan \u00e7a\u011fr\u0131lar\u0131n talep edildi\u011fi durumlard\u0131r. API \u00e7a\u011fr\u0131lar\u0131n\u0131 h\u0131zland\u0131rmak i\u00e7in HTTP \u00f6nbellekleme mekanizmalar\u0131n\u0131 kullanabilir ve ekstra i\u015flem gerekmez. Bu, GraphQL’in aksine t\u00fcm GraphQL sorgular\u0131 ana GraphQL u\u00e7 noktas\u0131na POST sorgular\u0131 oldu\u011fundan, bunu yapmak i\u00e7in potansiyel olarak daha fazla araca ihtiya\u00e7 duyabilir.<\/p>\n\n\n\n
REST API’leri i\u015flemleri farkl\u0131 u\u00e7 noktalara b\u00f6ler ve t\u00fcm \u00e7a\u011fr\u0131lar tek bir d\u00fc\u011f\u00fcm \u00fczerinden \u00e7al\u0131\u015fmaz. Bu, Distributed Denial of Service (DDoS) sald\u0131r\u0131lar\u0131n\u0131 tespit etmeyi ve kapatmay\u0131 kolayla\u015ft\u0131r\u0131r. GraphQL, etkili bir \u015fekilde tek bir u\u00e7 noktadan ge\u00e7en genel sorgular kulland\u0131\u011f\u0131ndan, bunu yapmak daha zordur.<\/p>\n\n\n\n
Kotalar ve h\u0131z limitleri gibi s\u0131n\u0131rlay\u0131c\u0131 mekanizmalar, a\u015f\u0131r\u0131 kullan\u0131m\u0131 \u00f6nlemek ve daha da \u00f6nemlisi, k\u00f6t\u00fc niyetli bir sald\u0131r\u0131 durumunda meydana gelebilecek hi\u00e7bir \u015feyin \u00fcstesinden gelinmedi\u011finden emin olmak i\u00e7in API’ye yap\u0131lan \u00e7a\u011fr\u0131lar\u0131n s\u0131kl\u0131\u011f\u0131n\u0131 s\u0131n\u0131rlamak i\u00e7in kullan\u0131l\u0131r. REST, h\u0131z s\u0131n\u0131rlar\u0131n\u0131n nispeten kolay bir \u015fekilde uygulanmas\u0131na ve talep edilebilecek veri t\u00fcrlerinin kolayca tan\u0131mlanmas\u0131na olanak tan\u0131r. Bu ayn\u0131 zamanda API u\u00e7 noktalar\u0131 i\u00e7in API sa\u011flay\u0131c\u0131s\u0131 taraf\u0131ndan bir plana veya API’nin kendisindeki trafik ko\u015fullar\u0131na g\u00f6re denetlenebilen bireysel h\u0131z s\u0131n\u0131rlar\u0131na da izin verir. <\/p>\n\n\n\n
Kimlik do\u011frulama mekanizmalar\u0131n\u0131n REST \u00fczerinde uygulanmas\u0131 genellikle GraphQL \u00fczerinde uygulanmas\u0131ndan daha basittir. GraphQL kullan\u0131c\u0131lar\u0131, bir API’nin \u00e7al\u0131\u015fmas\u0131 i\u00e7in olduk\u00e7a kritik olan REST’e k\u0131yasla yetkilendirme ile ilgili ek i\u015fler yapmak zorunda kalabilir. Bu muhtemelen zaman i\u00e7inde de\u011fi\u015fir. Ancak \u015fimdilik REST, kimlik do\u011frulamas\u0131n\u0131 ele almak i\u00e7in daha olgun bir \u00e7er\u00e7evedir.<\/p>\n\n\n\n
GraphQL’in t\u00fcm faydalar\u0131n\u0131 belirtmi\u015f olsak da, REST kullanman\u0131n da bahsetmeyi hak eden birka\u00e7 faydas\u0131 vard\u0131r.<\/p>\n\n\n\n
Bu avantajlar \u015funlar\u0131 i\u00e7erir:<\/p>\n\n\n\n
GraphQL, sunucudan tam olarak istedi\u011finiz verileri alman\u0131z\u0131 sa\u011flar, bu da zor bir g\u00fcvenlik sorununa yol a\u00e7ar. E\u011fer bir sald\u0131rgan korumas\u0131z bir sunucuya DDoS (Denial-of-service-attack) yapmak isterse, tek yapmas\u0131 gereken sunucunuzu a\u015f\u0131r\u0131 y\u00fcklemek i\u00e7in pahal\u0131 bir i\u00e7 i\u00e7e sorgu \u00e7al\u0131\u015ft\u0131rmakt\u0131r. Veri almak i\u00e7in ayr\u0131 HTTP \u00e7a\u011fr\u0131lar\u0131 kulland\u0131\u011f\u0131n\u0131z REST’te durum b\u00f6yle de\u011fildir.<\/p>\n\n\n\n
REST ile API yan\u0131tlar\u0131n\u0131 kullanabilir ve hata mesajlar\u0131 i\u00e7in bir izleme sistemi olu\u015fturabilirsiniz. Ancak GraphQL’de hata raporlamas\u0131, her yerde bulunan “200 K Error – Something went wrong” mesaj\u0131 ile arzulanan \u00e7ok \u015fey b\u0131rak\u0131r.<\/p>\n\n\n\n
HTTP \u00f6nbellekleri, modern taray\u0131c\u0131lar taraf\u0131ndan kaynaklar\u0131 tan\u0131mlamak ve iki kayna\u011f\u0131n ayn\u0131 olmad\u0131\u011f\u0131ndan emin olmak ve yeniden almay\u0131 \u00f6nlemek i\u00e7in kullan\u0131l\u0131r. GraphQL ile evrensel bir tan\u0131mlay\u0131c\u0131 kullanman\u0131n bir yolu yoktur \u00e7\u00fcnk\u00fc t\u00fcm istekler i\u00e7in ayn\u0131 URL kullan\u0131l\u0131r. GraphQL’de kendi \u00f6nbelle\u011finizi kurman\u0131z gerekir ki bu da olduk\u00e7a yorucudur.<\/p>\n","protected":false},"excerpt":{"rendered":"
Herhangi bir modern platform i\u00e7in kod yazd\u0131ysan\u0131z, kesinlikle bir web API ile etkile\u015fime girmi\u015fsinizdir. \u00c7o\u011fu zaman bu API muhtemelen REST’tir. Uzun s\u00fcredir programlama yap\u0131yorsan\u0131z veya…<\/p>\n","protected":false},"author":11,"featured_media":8064,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[48],"tags":[],"class_list":["post-8063","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programlama"],"yoast_head":"\n