想在rest风格API中提供图形验证码,发现有多处问题:
1.依据rest规则,所有get操作应该不改变服务器状态,但是图形码是直接嵌入在img中使用的。如下图片代码:
<img src='/api/v1/captcha?t=13249234'/>
每次刷新,都应该重置服务器上的验证码,但如果用post,代码就会显得很诡异,请问怎么解决?
2.rest是无状态协议,而常见的captcha类库都用到了session,请问是不是要为rest api重写captcha的类库?
想在rest风格API中提供图形验证码,发现有多处问题:
1.依据rest规则,所有get操作应该不改变服务器状态,但是图形码是直接嵌入在img中使用的。如下图片代码:
<img src='/api/v1/captcha?t=13249234'/>
每次刷新,都应该重置服务器上的验证码,但如果用post,代码就会显得很诡异,请问怎么解决?
2.rest是无状态协议,而常见的captcha类库都用到了session,请问是不是要为rest api重写captcha的类库?
看了下上面的答案,回答一波:
/api/v1/captcha?t=11111111
/api/v1/captcha?t=22222222
参考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来实现。
我的结论(看法),REST是一种架构风格,是一组架构约束,实际上,就像Roy博士在论文中提到,应用这一架构风格可以验证我们系统设计过程时的不足与疏忽,识别出架构缺陷。
当然,关于要不要破坏REST的约束,我个人认为,,是可以的,具体看不同设计吧,但要确保了解我们所正使用的东西的实际含义,及其设计出来的意义。毕竟,前人(那些大牛)很可能想的比我们远。而且就算绕过了REST去使用HTTP/1.1,而HTTP/1.1本来就是Roy博士将REST应用于旧有的HTTP而产生的呀。
以上,
如有异议,欢迎交流。
REST可以实现会话的啊。
POST一个请求给/session创建一个会话资源/session/1234,1234就是会话的ID。返回的HTTP 201 Created里面有session_created的数据,包括一个动态的会话口令(签名),以及新会话资源的URL。
带着这个口令(签名)GET请求会话资源/session/1234/captcha,相当于获取这个会话的一个属性,也可以往里面/session/1234/里面PUT别的东西。这样就可以和CAPTCHA结合起来了。
15 回答8.4k 阅读
8 回答6.2k 阅读
1 回答4k 阅读✓ 已解决
3 回答1.8k 阅读✓ 已解决
3 回答6k 阅读
2 回答2.2k 阅读✓ 已解决
3 回答2.2k 阅读✓ 已解决
GET /api/v1/captcha/13249234
服务端路由处理好即可,可以理解为13249234
就是验证码
这个资源的标识符,不是验证码里面的内容