符合rest风格的图形验证码应该是怎样的？

Question

想在rest风格API中提供图形验证码，发现有多处问题：
1.依据rest规则，所有get操作应该不改变服务器状态，但是图形码是直接嵌入在img中使用的。如下图片代码：

<img src='/api/v1/captcha?t=13249234'/>

每次刷新，都应该重置服务器上的验证码，但如果用post，代码就会显得很诡异，请问怎么解决？
2.rest是无状态协议，而常见的captcha类库都用到了session，请问是不是要为rest api重写captcha的类库？

Answer 1

GET /api/v1/captcha/13249234 服务端路由处理好即可，可以理解为13249234就是验证码这个资源的标识符，不是验证码里面的内容

Answer 2

rest不一定是写死的规则，get改变服务器状态也不是不可以，有时候风格是风格，业务是业务。

Answer 3

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

1. 首先
   /api/v1/captcha?t=11111111
   和
   /api/v1/captcha?t=22222222
   本来就是两条URI呀。

   详见：
   维基百科 | 统一资源标志符

2. 参考REST设计者的定义：Roy Thomas Fielding | 架构风格与基于网络的软件架构设计。

   会话（session）是一种资源，Roy Thomas Fielding | 架构风格与基于网络的软件架构设计 | 5.2.1.1。
   而REST是无状态的，Roy Thomas Fielding | 架构风格与基于网络的软件架构设计 | 5.1.3。

   所以，使用session本来就是破坏了REST的约束。但是，同时Roy博士在5.1.3节中，这里是需要权衡的。

   与大多数架构上抉择一样，无状态这一约束反映出设计上的权衡。其缺点是：由于不能
   将状态数据保存在服务器上的共享上下文中，因此增加了在一系列请求中发送的重复数据
   （每次交互的开销），可能会降低网络性能。此外，将应用状态放在客户端还降低了服务器
   对于一致的应用行为的控制，因为这样一来，应用就得依赖于跨多个客户端版本的语义的正确实现。

   当然，如果要保持stateless，可参考这里的答案stack Overflow | Do sessions really violate RESTfulness?，通过第三方auth来实现。

3. 我的结论（看法），REST是一种架构风格，是一组架构约束，实际上，就像Roy博士在论文中提到，应用这一架构风格可以验证我们系统设计过程时的不足与疏忽，识别出架构缺陷。

   当然，关于要不要破坏REST的约束，我个人认为，，是可以的，具体看不同设计吧，但要确保了解我们所正使用的东西的实际含义，及其设计出来的意义。毕竟，前人（那些大牛）很可能想的比我们远。而且就算绕过了REST去使用HTTP/1.1，而HTTP/1.1本来就是Roy博士将REST应用于旧有的HTTP而产生的呀。

以上，
如有异议，欢迎交流。

Answer 4

用ajax发post请求 渲染img标签可行否

Answer 5

验证码接口可以接受一个token，返回一个图片资源，前端生成一个token，获取验证码图片，校验的时候将token和用户的输入值传给校验接口。

Answer 6

REST可以实现会话的啊。
POST一个请求给/session创建一个会话资源/session/1234，1234就是会话的ID。返回的HTTP 201 Created里面有session_created的数据，包括一个动态的会话口令（签名），以及新会话资源的URL。
带着这个口令（签名）GET请求会话资源/session/1234/captcha，相当于获取这个会话的一个属性，也可以往里面/session/1234/里面PUT别的东西。这样就可以和CAPTCHA结合起来了。