为什么HTTP接口可以用COOKIE,那为什么需要设计成无状态的?
写接口的时候,HTTP请求命名可以设置COOKIE,将cookie带到服务端,为什么接口需要设计成无状态的,有什么好处?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
写接口的时候,HTTP请求命名可以设置COOKIE,将cookie带到服务端,为什么接口需要设计成无状态的,有什么好处?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(9)
你首先要知道
Cookie
是怎样产生的, 如我们第一次通过浏览器访问一个web服务,在服务端会产生一个会话信息Session
, 该服务器响应你的请求时会将该会话信息的session_id
以 cookie 写入到你的浏览器,下次访问时,会带着这个cookie信息进行会话验证;而 APP 的接口是没有通过浏览器访问的,所以也就在服务器端不会生成session,在客户端也不会写入cookie,那么也就拿不到会话信息,所以,为了能够像浏览器那样记住同一客户的信息,
Token
就诞生了, 用户每次访问服务端时,会带着这个Token,而服务端通过这个Token拿到用户的相关信息,然后再处理。我觉得的吧,这个是需要看具体的应用场景的。(无状态api=>restful)
引用知乎上某大神的说法,restful使用场景是Machine-to-machine的系统集成,目标是让服务发布者和消费者在最小约束下自由演化。
这个约束是指服务契约,简单讲就是服务输入输出的语义。消费者只需知道服务的根资源的URI,就可以由根资源引导到所需的资源。换句话说,消费者和发布者的耦合只在于根资源的URI以及各资源及其操作的语义。这样做的好处如下:
1.服务自解释
2.降低服务的版本粒度
3.降低消费者对服务内部实现细节的耦合,不需要考虑上下文,以及当前状态,极大的降低了耦合。
4.restful基于http,本身提供了丰富的内容协商手段,无论是缓存,还是资源修改的乐观并发控制。都可以以业务无关的中间件来实现。
而采用cookie,则是为了记录某种状态,用来实现上下文贯通,记录访问者状态的手段。保存在客户端的cookie确实容易被盗取,但是通过一些加密等安全手段也是可以增强安全性。
Cookie
是Http
协议的补充部分,主要是为了解决标记用户状态的问题(比如登录状态,通常用于MVC
程序中),但HTTP
接口通常应设计成无状态的,以方便扩展,所以不应该使用Cookie
,没有必要也不安全。节约资源吧,css也是http请求,记住css的状态不是有点浪费
我觉得吧,api的安全性更重要些。
浏览器的cookie可以自动处理一些东西,比如关了浏览器会话cookie就过期,可以从一定程度上确保会话的安全性。但是api请求的话你不知道他啥时候会“关浏览器”,而且涉及到一些金额变更什么的接口,如果一直用cookie的话可能会存在安全隐患。api可以设计成每次都带上不同的token,即使是同个接口同样参数,也是可以加上时间参数确保同样的token不能无限使用的。
因为 接口可以在其他地方使用,不只是浏览器 比如 手机app端,那样的话就无法保证他的状态了(但现在大部分app有封装支持cookie的),所以说通信的时候要带一个token来做用户认证。?
大部分http请求都是不需要保存用户状态的,比如我们浏览web页面,大多数时候你也不会想要去登录。但也有很多情况我们需要保存用户状态。所以Cookie和Session诞生了!
“无状态”指是 HTTP 协议,它是一个请求,一个响应,就结束了。而多个请求之间是否存在关系,这是你利用 HTTP 实现你的业务逻辑的事,是否有状态,也是你自己怎么实现的事。绝大部分在这个层面都不是“无状态”的。
更多地,你自己去了解一些其它的非 HTTP 的应用层协议,自然就明白了。
cookie不安全,如果接口携带cookie,那么抓包就可以拿到,拿到cookie的人,就可以随便任意访问接口了