符合rest風(fēng)格的圖形驗證碼應(yīng)該是怎樣的？

GET /api/v1/captcha/13249234 服務(wù)端路由處理好即可，可以理解為13249234就是驗證碼這個資源的標(biāo)識符，不是驗證碼里面的內(nèi)容

rest不一定是寫死的規(guī)則，get改變服務(wù)器狀態(tài)也不是不可以，有時候風(fēng)格是風(fēng)格，業(yè)務(wù)是業(yè)務(wù)。

REST可以實現(xiàn)會話的啊。
POST一個請求給/session創(chuàng)建一個會話資源/session/1234，1234就是會話的ID。返回的HTTP 201 Created里面有session_created的數(shù)據(jù)，包括一個動態(tài)的會話口令（簽名），以及新會話資源的URL。
帶著這個口令（簽名）GET請求會話資源/session/1234/captcha，相當(dāng)于獲取這個會話的一個屬性，也可以往里面/session/1234/里面PUT別的東西。這樣就可以和CAPTCHA結(jié)合起來了。

用ajax發(fā)post請求 渲染img標(biāo)簽可行否

看了下上面的答案，回答一波：

1. 首先
   /api/v1/captcha?t=11111111
   和
   /api/v1/captcha?t=22222222
   本來就是兩條URI呀。

   詳見：
   維基百科 | 統(tǒng)一資源標(biāo)志符

2. 參考REST設(shè)計者的定義：Roy Thomas Fielding | 架構(gòu)風(fēng)格與基于網(wǎng)絡(luò)的軟件架構(gòu)設(shè)計。

   會話（session）是一種資源，Roy Thomas Fielding | 架構(gòu)風(fēng)格與基于網(wǎng)絡(luò)的軟件架構(gòu)設(shè)計 | 5.2.1.1。
   而REST是無狀態(tài)的，Roy Thomas Fielding | 架構(gòu)風(fēng)格與基于網(wǎng)絡(luò)的軟件架構(gòu)設(shè)計 | 5.1.3。

   所以，使用session本來就是破壞了REST的約束。但是，同時Roy博士在5.1.3節(jié)中，這里是需要權(quán)衡的。

   與大多數(shù)架構(gòu)上抉擇一樣，無狀態(tài)這一約束反映出設(shè)計上的權(quán)衡。其缺點是：由于不能
   將狀態(tài)數(shù)據(jù)保存在服務(wù)器上的共享上下文中，因此增加了在一系列請求中發(fā)送的重復(fù)數(shù)據(jù)
   （每次交互的開銷），可能會降低網(wǎng)絡(luò)性能。此外，將應(yīng)用狀態(tài)放在客戶端還降低了服務(wù)器
   對于一致的應(yīng)用行為的控制，因為這樣一來，應(yīng)用就得依賴于跨多個客戶端版本的語義的正確實現(xiàn)。

   當(dāng)然，如果要保持stateless，可參考這里的答案stack Overflow | Do sessions really violate RESTfulness?，通過第三方auth來實現(xiàn)。

3. 我的結(jié)論（看法），REST是一種架構(gòu)風(fēng)格，是一組架構(gòu)約束，實際上，就像Roy博士在論文中提到，應(yīng)用這一架構(gòu)風(fēng)格可以驗證我們系統(tǒng)設(shè)計過程時的不足與疏忽，識別出架構(gòu)缺陷。

   當(dāng)然，關(guān)于要不要破壞REST的約束，我個人認(rèn)為，，是可以的，具體看不同設(shè)計吧，但要確保了解我們所正使用的東西的實際含義，及其設(shè)計出來的意義。畢竟，前人（那些大牛）很可能想的比我們遠。而且就算繞過了REST去使用HTTP/1.1，而HTTP/1.1本來就是Roy博士將REST應(yīng)用于舊有的HTTP而產(chǎn)生的呀。

以上，
如有異議，歡迎交流。

驗證碼接口可以接受一個token，返回一個圖片資源，前端生成一個token，獲取驗證碼圖片，校驗的時候?qū)oken和用戶的輸入值傳給校驗接口。