ofthesessionapi下写在前面时间：2017-05-297:30距离上一篇文章发表已经一个多月了。原计划一周录一次，怎么变了？程悦还记得吗？最近工作太忙了，当然不能排除懒得不行的因素，为什么有时间就不能写博客呢？暗暗自责了一分钟……今天是端午小长假的第二天。第一天，我和舍友约好了去颐和园，但帝都36度的高温让我望而却步。于是这几个哥们又把手机关到天黑，一直开到深夜。昨天浪费了一天的时间，今天早上起来满怀着继续昨天计划的雄心壮志，可是这些老人家却再也没有起床。我心地善良，觉得打扰别人的梦太不礼貌了，那还是写个博客吧，把这一个多月来的乱七八糟的事情处理一下，不然的话，月记就得写了成人。对了，在此之前，先祝大家端午节快乐！嘎嘎文本切入正题。回顾一个多月的乱七八糟的事情，其实我是一个传统的PHP程序员，拿着一套没有用户登录状态的App界面，想着如何使用session建立用户会话，将用户信息和登录状态保存在接口服务器。这里要吐槽一下ci框架，奇葩的重写session机制，让我在postman中获取不到session值，浪费了很多时间。所以战友们慎重选择框架！我拿到的API接口没有做任何请求校验，也就是任何人拿到接口地址后都可以直接调用，极不安全。一想到认证，我首先想到的就是传统的cookie+session机制。但是一般的API都会在请求参数或者请求头中添加一个token。所以我的方案是：用户登录验证通过后，在服务器session中保存用户信息和匹配的token，然后将token返回给客户端，表示登录成功。用户后续的每一次请求操作都需要将token带入请求头中。这样做相当于增加了两层验证。第一层是session验证，传统的web后台验证方式。第二层是将请求头中的token与session中的token进行匹配，全部通过后，才能运行接口中的逻辑。安检做好了，下一步就是去接客户了。其实在access之前，我就被小粉丝嘀咕了一句，client不会get到session吧？果然怕什么，Android告诉我session错误，取不到值。其实这很正常。会话在Web开发中使用起来简单快捷，因为浏览器为我们做了很多事情。比如创建session时，浏览器返回的responseheader中会有一个Set-Cookie选项，帮助我们在浏览器本地创建一个cookie，用于保存上一步创建session时生成的sessionid，然后会在下一个请求中展示，在请求头中带上这个cookie，通过cookie中的sessionid找到对应的session数据。就像一个session是一个user表一样，cookie中的sessionid就是user表的主键id。浏览器获取session数据的过程就像是通过主键ID在数据表中查找一条数据的过程。但是在API中，虽然可以接收到responseheader中的set-cookie，但是下一个requestheader中不会自动添加cookie。如果没有发送sessionid，自然查不到session数据。所以在API中，发送请求头中的cookie需要我们手动完成。和Android沟通，他们说可以在框架中模拟浏览器行为，实现cookies的自动发送。但是这套接口不仅是针对app的，PC端的网页也是可以的。如果想在phpcurl请求接口的时候手动查找并发送cookie，无疑会增加接口的负载，而且会很麻烦。想来想去，我们决定放弃这种验证方式。我比较纠结的是，如果不用session，调用获取用户信息的接口时至少要传入user_id作为参数，但是session模式不识别这个方法，因为必须要获取用户信息从登录后的会话中，而不是直接通过客户端传递，这会有风险。同时，session最重要的是保存用户的登录状态。如果没有会话，你怎么知道当前用户是谁？你登录了吗？登录是否过期？转不过来，于是查了百度，浏览了论坛，翻来覆去，终于找到了关键的一句话：API是无状态的。是的，API是无状态的，至少restful是！API是无状态的，一开始没看懂，但它的合理性也在慢慢被证实。如果api是无状态的，那么状态只能存在于app客户端中。事实上，这是真的。Web中的用户状态存在于服务端，而APP存在于客户端。还有一种情况，就是现在流行的前后端分离架构，用户状态应该存放在哪里呢？记得以前看过相关文章。解决方案是在前端和API之间加一个节点作为中间层。我一直不知道这一层节点是干什么用的，但是按照我目前的理解，这一层节点负责请求API，然后创建和维护session。我就是这样做的，到目前为止它似乎很有效。所以，说了这么多，心里满是疑问和抱怨。如果你认为web开发和api开发的区别在于前者渲染页面，后者输出数据，那么session将是你绕不开的一个梗。session机制没有像笔试题中session和cookie的区别答案那样弱智。至少需要补充一下http的知识，才能看懂request和response。回到标题，api下用的session吗？标题末尾有个问号，大家自己想想吧。如果你没有复杂的会话，也许jwt是你更好的选择。本文由杨成功原创。更多原创内容，请前往杨成功的全栈之路专栏
