RESTful的定義是無狀態(tài)，token更符合這一點(diǎn)，每次請求都傳遞參數(shù)token，無狀態(tài)的交互形式。
而我們都知道http是無狀態(tài)的，所以每次都要帶上狀態(tài)去請求服務(wù)器也就是 Cookie/SessionID，cookie機(jī)制采用的是在客戶端保持狀態(tài)的方案，而session機(jī)制采用的是在服務(wù)器端保持狀態(tài)的方案。

不管token很是session_id原理上都是差不多的，token通常是放在接口直接請求，token通常是放在header中進(jìn)行請求，不管怎么樣都需要前后端發(fā)起數(shù)據(jù)交互。不管用token還是session，都沒大關(guān)系，只要能實(shí)現(xiàn)即可。

可以看下jwt這種token，是不需要存在服務(wù)器的，所有認(rèn)證信息（用戶id，過期時(shí)間等）是被加密在token當(dāng)中的，在服務(wù)端解密token就可以獲取認(rèn)證信息，不像session需要在服務(wù)器那里，根據(jù)cookie來取回狀態(tài)。

至于安全問題，jwt+https基本是很安全的了。這種stateless的token還有個(gè)好處是他可以無痛拓展，因?yàn)閟ession的文件是存放到磁盤上的，當(dāng)你有第二臺(tái)服務(wù)器時(shí)，為了共享登陸，你不得不把session文件轉(zhuǎn)移到redis或其他介質(zhì)上，而jwt本身自帶所有認(rèn)證信息，直接使用

很多人是按session的方式來使用token，所以覺得兩者一樣。

session思維是這樣：傳遞sessionID或者所謂的token到服務(wù)端，然后服務(wù)端根據(jù)這個(gè)鍵值找到用戶數(shù)據(jù)，也許是session文件，也許在redis里，然后讀取里面的數(shù)據(jù)uid=1，至此用戶身份確立。

而真正的token思維是這樣：uid=1直接保存在客戶端，當(dāng)然不會(huì)只保留這么簡單的數(shù)據(jù)，很容易偽造。實(shí)際保存數(shù)據(jù)可能是這樣uid=1|6166b2002fdcb5df，后面一部分簽名是根據(jù)第一部分?jǐn)?shù)據(jù)加密所得，而加密算法只有服務(wù)端知道，你就沒辦法偽造數(shù)據(jù)了。服務(wù)端獲取這個(gè)token后，對第一部分?jǐn)?shù)據(jù)驗(yàn)簽，和第二部分比對，如果一致，直接確立用戶身份uid=1。整個(gè)操作直接在內(nèi)存中運(yùn)算，不需要讀取session文件或redis。你甚至可以把整個(gè)用戶信息uid=1&nickname=xxx&money=1000保存到token里。

比如常用的JWT，是用 . 分割成3部分，每部分再base64_encode，但思路是一樣的。

雖然我不是大神，但是可以介紹一個(gè)大神

Token 認(rèn)證的來龍去脈 segmentfault.com/a/1190000013010835 by 邊城

如果我們把所有狀態(tài)信息都附加在 Token 上，服務(wù)器就可以不保存。但是服務(wù)端仍然需要認(rèn)證 Token 有效。不過只要服務(wù)端能確認(rèn)是自己簽發(fā)的 Token，而且其信息未被改動(dòng)過，那就可以認(rèn)為 Token 有效——“簽名”可以作此保證。平時(shí)常說的簽名都存在一方簽發(fā)，另一方驗(yàn)證的情況，所以要使用非對稱加密算法。但是在這里，簽發(fā)和驗(yàn)證都是同一方，所以對稱加密算法就能達(dá)到要求，而對稱算法比非對稱算法要快得多（可達(dá)數(shù)十倍差距）。更進(jìn)一步思考，對稱加密算法除了加密，還帶有還原加密內(nèi)容的功能，而這一功能在對 Token 簽名時(shí)并無必要——既然不需要解密，摘要（散列）算法就會(huì)更快?？梢灾付艽a的散列算法，自然是 HMAC。

問題的出處在哪里？誰這么說了？表示疑問。。
RESTful 的定義里有關(guān)于 token 的說法？
說我的理解吧，不管是 token 還是 session 都只是標(biāo)識(shí)請求來源，是哪個(gè)用戶請求的。
換種說法，網(wǎng)站的 api 實(shí)現(xiàn)，我明明可以用 session 的為什么要有 token ？多此一舉 。