应该怎么与这位同事（程序员）沟通？

[yuankui]

事情是这样的
我和另外一个同事在做一个APP服务端，用的是spring-mvc（由于要尽快发布，因此各个模块的实现较为粗糙）
登录（验证）模块是这位同事做的，今天我简单看了一下，实现方式是要求客户端每次请求，所有的请求都带上用户名密码，然后有个入口来验证这个用户名密码（查询数据库），然后再交给后续的流程处理。
是的，这里的问题很多。我就提出了不能每次请求来都查询数据库

我：同学，你这个验证模块是每次都要查询数据吗？
同学：哦，是的，（然后他好像发现这里是有问题得了），现在写的比较简单，我后面再搞一下
我：你打算怎么搞
同学：加个缓存吧
我：那直接用session呗，session不就是一个缓存吗？
同学：手机端又不是浏览器，怎么会有session
我：手机端也可以有啊，你让客户端往http请求加个cookie就好了啊
同学：那这么说客户端就麻烦了，有些客户端就不想写，你不能强迫客户端
我：这有什么强迫的，就set cookie，调个函数就完了，有什么问题吗？
同学：算了，我还是自己写个缓存吧
我：session不就是缓存吗？你何必自己造轮子呢？而且这里面有很多问题你要考虑的
同学：呵呵，你想多了，没那么复杂的
下文略。。。。

我真的想多了吗？
其实我的目的就是劝这位同事不要重复造轮子，应该是我说话的方式不对？请问该怎么跟他沟通？

[sumhat]

@yuankui 这种细节的设计也可以写一份单独的 spec，讨论通过了再编码，这样可以避免两个人之间没有意义的争论。

[skybr]

我感觉你不走db或cache而只想通过session解决是只想记一个session["user.id"]这种方案?

但这样会出现一个问题， 在A设备上修改密码后原先在B设备上用老密码登录成功的还是有效的。

除非你在去维护一个session和user.id的映射关系， 然后人为销毁这些session; 或者你在session除了user.id外再设置一个user.token验证合法性, 某个终端修改后重设 , 但做验证的时候同样无法避免走一遍db或者cache.

你同事的办法虽然有点糙, 但要是保障走https, 反而比你的想法问题小.

[kemingcao]

这样的做法，我会推倒他的代码，自己花费半天时间把用户认证测试写出来。

[jarlyyn]

觉你的同事没什么大问题啊。这不就是一个HTTP basic验证么。在oauth普及前本来也是一个比较常见的api解决方案吧。
以REST来说，不用session也算 符合 state-less的标准啊。
既然你的问题是是否每次都需要查询数据库，那么的确做个缓存就可以了……

其实session也要考虑很多问题啊。客户端的储存与过期处理，服务器端的集群处理，用户session的注销等。

既然缓存能解决，何必用更重的session呢。

[Jaylee]

session是一个缓存？

[paulw54jrn]

@skybr
用缓存的话，如果别的客户端改密码，只需要去缓存里面把记录失效就可以了？

[Hubert]

首先，如果你是在问你同事的解决方案有没有问题，作为一个渣程序员，我觉得在你描述的应用场景里面，你那同事做的是没有任何问题的。
你们做的是一个 API 服务器端，Session 、Cookie 这种玩意确实不是 API 身份验证好的解决方案。目前比较流行的应该是 OAuth，OAuth2 (目前各大开放平台 API 基本上都是用的这玩意)。@Jarlyyn 说了，在 OAuth 还没普及的时候 HTTP Basic 验证是一种很长见的验证方式。目前存在的问题是：每次查询数据库，但是你又说了，这是一个急着上线的项目，所以不盲目的做这种优化也没什么错。
个人浅见，缓存比 Session、Cookie 这种玩意靠谱多了。

如果你是问你跟你同事交流方面的问题，那我也觉得你同事没什么错。
一、你提的方案不正确，如果用你的方案 ，你到时候会发现这么多么坑爹的一件事情。
二、他面对你提的这种不合理的要求，还心平气和的跟你说，我觉得在程序员中，你同事的脾气应该算好的了。
三、“该同事工作经验应该算比我多个2-3年，他是不会会觉得我提出的办法比他好（假如），他会没面子”，从你这个言论来看，我觉得你心态没有你同事好。

[yuankui]

@Hubert 感谢你废了这么多口舌来跟我讲道理。
你们的话我会参考
场景里面可能涉及更多的背景和细节，可能是我也没能交待清楚，大家也忽略的东西。
所以还是谢谢大家的意见，我会好好反省，出一个比较好的结论，以及一个长期的解决方案（沟通方面）。

[jarlyyn]

@paulw54jrn 不需要失效，直接更新缓存就可以了。
假设缓存是 username对应hash后的密码的话

[njutree]

我觉得这就是你们公司没有统一做程序架构或设计的结果，每个人都有自己的设计思路导致项目里面很多耦合不必要的（轮子），而且没发统一。

[jarlyyn]

@yuankui

就沟通本身来说，我觉得你有个问题。

你只是提出了一个自己的觉得能够解决问题的方案，

你所有的沟通都没有否定对方的方案有效。

你也没有解决'有些人就是不愿意写session'的问题。

你在没有说服别人的请跨下(既没有证明别人的方法无效，也没有证明自己的发放更好)，却认为别人难以沟通，这才是问题。

PS，如果是session和http basic认证给我选的话，我真的会选http basic认证。
不论是request.js的jar,或者file_get_content的set_headers，都很蛋疼。

[avatasia]

认证的话，每次都必须查询数据库，至于性能上的缓存，不是你们前端该操心的事情，老老实实用db查询。

还有如果是app的话，尽管实现session是没问题的， 但是现在谁还用这种老土的方式？

请google authorize token。

[realityone]

我设计的一般是登录成功就返回一个 token
后续靠 token 来操作
token 就存在 redis 里好了

[DRcoding]

像这种情况，如果不想查询数据库的话，客户端和服务端用Base64约定同一个加盐的方式验证就可以了，只要加盐方式不泄露的话。

[jarlyyn]

回家的路上边开车边想，其实楼主的做法有点坑啊。

首先session本身并不是一个缓存，session本身是有过期时间的token以及对应的数据，一般构建在缓存之上。以express为例，其实session本身是构建在mysql/nosql/redis/文件/内存上的，而不是缓存本身。php的话道理也一样。也就是说，session本身是一个需要缓存的东西，而非缓存。后期去用session实现缓存本质上是多次一举了，还要复出更大的代价，以及无法在别的需要缓存的地方复用。

再说客户端。如果要使用session, 那么必须要考虑过期，过期后需要用专门的接口认证，也就是基本上实现半个oauthtoken。那别人不用县城的oauth库，去使用session，不是自己和自己过不去啊。

[yuankui]

@jarlyyn 我回家的路上也在想，确实比较坑。。
我原意是把session当做cache来用了。后来发现session过期之后客户端的操作更加繁琐。
现在我们本事不用oauth其实可以的，只要请求是通过https的就行。

[winiex]

刚开始设计 API 的时候就应该 RESTful 化，然后加上一个基于 Oauth 2.0 的验证机制，就不会出现类似的问题了。当然这个在你现在的情境下比较不现实。

如果是我的话，我会拉这个哥们一起喝点东西，然后请他按照更科学的方式来做。

[shajiquan]

你同事做的没什么问题，很常规的策略。他加缓存的话，会适当地减轻库的压力。但你们才刚开始，用的着加缓存么？加大开发量，增加复杂度。

验证这种事情，客户端只需要把 auth key 和 user id 之类的传上去，全部由服务端来处理就好了。客户端不需要搞这些。尤其是，未来单点登录多点登录之类的问题出现的时候，服务端调起来也更方便。

[bolasblack]

实话说，所有请求带上帐号密码最严重的问题并不是性能问题吧？最严重的是安全问题吧？？？？

你们的 API 是 https 的嘛？没有的话人家随便截个包那用户的密码就暴露了呀，这是上个世纪的做法吧？

我简单看了一下，发现上面的人说的都不在点子上，这种做法，从根子上就有问题，完全就不应该这么干，就算解决了性能问题也不行

用个 token 怎么了？客户端能死啊？才加了多少难度啊，自己包装一个发起请求的函数然后在这个函数里加 token 有什么难度么？我就是做客户端的，我之前也有一个写服务端的同事像你那个同事那么干，我直接和他说这有问题

这不是经验与否的问题，如果他不是因为项目期限或者什么原因而不愿意改，在我看来，这是责任心的问题

至于解决方案，oAuth 2.0 稍微有点复杂了，建议使用 JWT ，介绍： http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/

我有一个 repo 写了一些设计 API 时的建议，我推销一下： https://github.com/bolasblack/http-api-guide

[bolasblack]

而且 JWT 协议本身也能实现类似缓存的功能