一次接口设计的反思

最近在公司负责一个小程序项目的后台开发，设计接口的时候没想太多，现在回头来看问题太多
当时的需求是要求用户第一次进入小程序时绑定账号，之后进入小程序的时候就不用绑定账号。如果绑定了账号就返回用户的商户列表。
当时接口设计最大的败笔是将绑定账号的接口设计成直接返回商户列表，并包含了放用户号到缓存的操作，导致绑定账号的接口业务逻辑过于复杂。应该保证一个接口只干一件事。
由于微信有一个通过用户临时登录凭证code去获取openid这个初始化的操作，还需要一个init方法，我选择在init方法中返回用户是否绑定的信息。

现在的设计流程是：

用户未绑定的情况需要 init ，查绑定关系-》绑定用户，放缓存-》根据用户号获取商户列表
用户已绑定的情况下需要 init ，查绑定关系，放缓存-》 根据用户号获取商户列表

看上去有两种其他选择
1，增加一个判断是否绑定的接口，这样
在用户未绑定的情况下，init-》查绑定关系-》用户绑定，放缓存-》根据用户号获取商户列表
在用户已绑定的情况下就走 init-》查绑定关系，将用户号放入缓存-》查商户列表
2，将判断绑定的逻辑放在商户列表接口中，这样
在用户未绑定的情况下 init-》查绑定关系 -》绑定-》查绑定关系，放缓存，查商户列表
在用户已绑定的情况下就走 init-》查绑定关系，将用户号放入缓存，查商户列表

因为用户号放缓存这个动作在两个地方出现，这样会导致混乱，实际开发时就漏掉了导致了bug。但是现在看来除非选择方法二，多查一次数据库，否则无法避免这个情况。也许应该将查绑定关系数据库这个动作放入切面，每次用到用户号时都正常取缓存，如果没有值就去访问数据库获得此值（或者不用切面在get方法中直接处理）。那么方法二就变成
init-》取缓存（如果值为空自动去查数据库并放缓存），查商户列表。

还有一个可选的选择是把用户号传给前端，让他在请求的时候发过来，这样就用不到缓存了，但是这样做可能会有安全方面的问题。说到安全顺便想说，一个没多少代码，估计500行的项目，已经用到了SM2/SM3/SM4/RSA四种加密算法。。

接口设计应该尽量做到：
1.尽量保证接口名和实际动作一致，最好只干一件事。
2.尽量避免同一操作出现在不同方法里。