Öncelikle cevap verdiğiniz için teşekkür ederim. Kafam çok karışık mazur görün. Şimdi diyelim GET isteği gönderdim. Cevap bir linke JSON olarak mı yazdırılıyor? Bu linke herkes erişemiyor mu? DELETE isteği gönderdiğimde ne oluyor mesela?
Örneğin, kullanıcı giriş yapacak diyelim. Tam olarak nasıl bir yol izleniyor?
Bir de JSON Web Token diye bir token sistemi varmış, bunu kullanmak zorunda mıyız?
Çok parça parça yazdım kusura bakmayın.
Bence senin kafanda cok parca parda duruyor mesele, o yuzden bu kadar oturmamis gibi : ) Sorun yok istedigin kadar sor, arastirip geldigin belli en azindan.
JSON Web Token kullanmak zorunda degilsin. Ama bir token kullanmak durumundasin. JWT nin guzelligi, encryption ile token icerisine kullanici bilgilerinin gomulmesi. Yani standart bir token isleminde, token yalnizca kullaniciya ait gelisiguzel olusturulmus bir String. Sen bu string'i alip, hangi kullaniciya ait oldugunu veritabanina giderek bulmak durumundasin. JWT de ise durum farkli, token'in kendisi bilgi iceriyor. Bu biraz daha riskli aslinda guvenlik acisindan ancak veritabanina gereksiz git-gel lerin onune gectigi icin daha hizli. Bu belki isine yaramayacak bir detay ama JWT kullanmaniz sart degil. Hatta tam olarak ne yaptiginizi bilmiyorsaniz kullanmayin bence.
Cevabin JSON'a yazdirilmasi diye bir sey yok. En temel HTTP protokolune geri donelim; Request atarsin - Response donersin. Bu kadar. Her request ve response icinde bir "payload" barindirir. REST icin bu payload genelde JSON formatindadir. Bu kadar. JSON olmak zorunda bile degil aslinda. REST 'i REST yapan Request Methodlandirmasi ve URL isimlendirmesi; JSON degil.
Yani sen GET request i atarsin, server bunu degerlendirir ve sana bir response doner. Iste o response'un payload'i JSON icerecektir. Bu kadar basit. Her response payload icermek zorunda degil. Her request de ayni sekilde.
Kullanici girisi farkli bir mesele. Authenticate ve authorize iki farkli konsept.
Ahmet'in ahmet oldugundan nasil emin olursun? Ahmet'in kendine ait sifresini ve diger bilgilerini girmesini istersin. Buna "Authentication" denilir. Bir kisinin iddia ettigi kisi oldugundan emin olmaca. Aslinda bu hep bildigimiz login islemi. Ama sonucunda sen Ahmet'e bir token verirsin. Bu demektir ki " Ahmet'cigim ben seni tanidim ve sen hakkaten soyledigin kisisin. Al sana bu token'i. Bundan sonra bana istek yaptiginda her defasinda ben Ahmet'im demene gerek yok, bu token ile gelsen yeterli".
Iste bundan sonraki her request Ahmet tarafindan geldiginde senin ona verdigin token'i icermeli. O noktada server token i kontrol edecek
1) O token gercekten gecerli mi ( suresi dolmus mu vs )
2) O token'a sahip birisi bu request e yetkili mi ( Ornegin Ahmet kendi token'iyla tum user listesini cekebilir mi )
Bu islem de authorization. Kisinin kim oldugunu umursamadan, yapilacak isleme yetkisi olup olmadigini degerlendirme proseduru.
Ben kapiciyim. Herkese ekmek alirim ama sadece apartman yoneticisine sut alirim.
Apartmana giren herkes bekciye kendini tanitiyor. Bekci onlara "token" veriyor.
Ben kapici olarak ev ev gezip isteklerini soruyorum. Kapiyi cocuk da acabilir, eve gelen misafir de acabilir. Beni ilgilendirmez. Ben "token" a bakarim. Bekciyle konustum, hangi token'larin ekmek, hangi tokenlarin sut almasi gerektigini biliyorum. Token'a bakarim token mi diye, sorana bakarim istegi makul mu diye : ) Eger her sey olmasi gerektigi gibiyse isimi yaparim.
Bu senaryoda bekci authenticate ediyor.
Kapici authorize ediyor.
Tum bu islemin amaci, bekci ve kapici sistemini birbirinden ayirmak ve herkesin isini kolaylastirmak. Hem guvenli, hem hizli hem pratik.
