【API】api 下 session 的 Yes or No?

寫在前面

時間：2017-05-29  7:30

距離上篇文章發佈已經一個多月了，原本本身的計劃是一週一記，怎麼就變成月記了呢？最近工做的事情忙的焦頭爛額，固然也不能排除我懶的要死的因素，有時間追擇天記怎麼就不能寫篇博客呢？暗暗自責一分鐘...

今天是端午節小長假的次日，第一天約好和舍友逛頤和園的計劃被帝都36度的高溫打回來了，因而乎這幫哥們又抱着手機開黑到深夜。昨天虛度了一天，今兒一早起來雄心滿滿的要繼續昨天的計劃，無奈這幾個老年人又不起牀。我善心做祟，想着打擾人家好夢太不禮貌，那就，寫篇博客吧，理一理一個多月來亂七八糟的事情，要否則，月記也得成年記了。

對了，在這以前，首先要祝你們端午節快樂！嘎嘎

正文

切入正題。回顧這一個多月亂七八糟的事情，其實就是一個傳統的PHP程序員，拿着一套沒有作用戶登陸狀態的App接口，在考慮如何利用session創建用戶會話，在接口服務端保存用戶信息和登陸狀態。

這裏要吐槽一下ci框架，奇葩的重寫session機制，搞得我在postman中就是獲取不到session的值，浪費很多時間。因此同志們，選擇框架要慎重啊！

我拿到的API接口，是沒有作任何請求驗證的，就是任何人拿到接口地址就能夠直接調用，這是極不安全的。我在考慮要作驗證的時候，首先想到的就是傳統的cookie+session機制。可是通常的API又會在請求參數或者請求頭中加一個token。因此個人方案是：當用戶登陸驗證經過以後，在服務端session中保存用戶信息和一個與之匹配的token，而後將該token返回客戶端，表示登陸成功。接下來用戶的每一次請求操做，都須要將該token帶到請求頭中。

這樣作至關於加了兩層驗證。第一層就是session驗證，傳統的web後臺驗證方式。第二層是將請求頭中token與session中的token匹配，所有經過，才能夠去跑接口中的邏輯。

安全性作到了，下面要接客戶端了。其實在接入以前，我就有點範嘀咕，客戶端不會拿不到session吧？果真怕什麼來什麼，安卓那邊告訴我session錯誤，取不到值。

其實這很正常，web開發中session用起來簡單快速，那是由於瀏覽器幫咱們作了不少事情。好比在session建立的時候，瀏覽器返回的響應頭中會有Set-Cookie的選項，幫咱們在瀏覽器本地建立cookie來保存上一步session建立時所生成的sessionid，而後下一次請求的時候又會在請求頭中帶上這個cookie，經過 cookie 中的 sessionid 找到對應的session數據。就比如 session 是一張用戶表，cookie 中的 sessionid 就是用戶表的主鍵 id，瀏覽器獲取 session 數據的過程就比如是經過主鍵 ID 查找數據表的某條數據的過程。

可是在API中，雖然能夠接收到響應頭中的 set-cookie, 卻不會在下一次的請求頭中自動添加 cookie。沒有發送sessionid，天然找不到 session 數據。因此在API中，發送請求頭中的cookie，須要咱們手動完成。

和安卓那邊溝通，他們表示框架中能夠模擬瀏覽器行爲，實現 cookie 的自動發送。可是這套接口不光給app用，pc網頁端也在用。若是要在 php curl 請求接口時手動去找 cookie 併發送，無疑會增長接口的負重，並且麻煩的很。思慮再三，咱們決定放棄這種驗證方式。

我糾結的是，若是不用session，那麼在調用獲取用戶信息接口的時候，至少要將user_id做爲參數傳過去，可是session模式對於這種方式是不承認的，由於用戶信息要在登陸以後從session獲取，而不是經過客戶端直接傳遞，這會有風險。同時session最關鍵的仍是保存用戶登陸狀態，若是沒有session，如何知道當前用戶是誰？是否在登陸狀態？是否登陸過時？

轉不過彎來，因而就去查百度，逛論壇，翻來覆去，最後發現一句話很關鍵：API是無狀態的。

對，API是無狀態的，至少 restful 是這樣！

API無狀態，開始不理解，但是它的合理性又在慢慢獲得證明。若是api無狀態，那麼狀態只能是存在app客戶端。事實上確是如此，web中用戶狀態存在服務器，而app存在客戶端。

還有一種情況，就是如今流行的先後端分離架構，用戶狀態又該存到哪？我記得以前看過相關的文章，解決方案是在前端與API之間加一個 node 做爲中間層。我一直不知道這層 node 是用來幹嗎的，不過按照如今理解，這層 node 負責請求API，而後建立和維護 session 會話。我就是按照這種方式去作，目前看來是可行的。

因此，扯了這麼多，疑問滿滿，牢騷滿滿。若是你以爲web開發和api開發的區別就是前者渲染頁面，後者輸出數據，那麼 session 會是你繞不開的梗。session機制不是筆試題上表述session和cookie區別的答案那麼弱智，你至少須要補充 http 的知識，理解請求和響應。

回到標題，api下是否使用session？標題的結尾是個問號，因此本身考慮嘍。若是你沒有session情結，或許，jwt是你更好的選擇。

本文由 楊成功 原創，更多原創內容請到專欄 楊成功的全棧之路