说明：以下是昨天和同事关于一个接口的讨论，我觉得很有意思，针对同一个问题大家从不同的角度来看接口设计的问题。记录下来可以为自己以后设计接口提供参考，更希望有对此有想法的人能一起探讨下（顺便拉小弟一把帮我进步一下）
背景
注册时需要对用户输入的密码进行一定的规则校验，页面和后端都校验（废话-_-）。但是我们的系统的 admin 可以对这个校验规则进行配置，实时修改。那么为了保证前后台校验规则的一致性，我们采取的方案是通过 ajax 从后台获取密码的校验规则（正则表达式），而不是在 javascript 里面写死。以下是接口及返回 demo 版本：
// interface http://xxx.xxx.com/xxx/xxx/login/access
/*
Response JSON:
{
data: {
...
pwdRegExp: "^(?=.*[\p{Digit}])(?=.*[\p{Lower}])(?=.*[\p{Upper}])[\d\p{Upper}\p{Lower}\p{Punct}]{8,20}$"
...
},
mcode: xxx
result: true
}
*/
接口返回的字段中 pwdRegExp 就是后台对密码的验证规则，它的值是 java 的正则表达式。页面收到这个字段后通过一个转换器把她转成 javascript 的正则表达式
function toJsRegExpMap( backendRegExp ) {
return new RegExp( backendRegExp.
replace(/\\p{Digit}/g, '\\d').
replace(/\\p{Lower}/g, 'a-z').
replace(/\\p{Upper}/g, 'A-Z').
replace(/\\p{Alpha}/g, 'a-zA-Z').
replace(/\\p{Punct}/g, PUNCT)
);
}
讨论
申明在前，我在这里记录下讨论绝对没有偏好，没有谁对谁错，只是想还原原来的讨论，我自己最后也承认这个问题我可以接受任何的合理的结论（A，C 是同事，B 是我，讨论有删减，不保证完全是原文）
A：这个api为什么不直接让他们提供一个可用的正则？如果是要js去转的话，就是说每个使用这个api的地方都要自己去转。这样肯定是不合理的。
B：为了保证前后端验证规则一致，后端传出它的正则，然后由其他系统去做其他系统的转换及 mapping，这个我个人认为是 make sense。因为后端不能保证它给出的前端正则和后端正则的校验结果能严格一致。（我假设后端开发人员对 js 不熟 - 这括号中是我写此文时候的补充，非原对话中有）
A：那使用api的各方各自转换能确保一致吗？这更走远了。输出api的那方直接给出正则，有问题改的也只是输出api的地方。
B：因为转换规则是其他系统所知，后端系统并不可知。
A：直接是隔离了问题。现在就 java 和 js，如果有再添加就行了。或者没有再转。
B：自己系统的问题自己维护，你转错了是你的问题，好比后端只给出规则，其他系统负责实现，只是这个规则以 Java 正则来表达的。
A：但是 java 和 js 这两种是肯定会有用的。
C: 因为现在只有 js 消费这个正则，如果这个接口同时需要为 php 提供服务的话，它不太会为所有消费者提供转换的 后台会变得太复杂了。
B：你一定说只有两系统，那传一传也可以，我是从系统隔离的角度考虑的。
A：转换没风险吗？还是使用 api 的各方自己转，怎么保证各方转换是对的？有多少个调用的地方就有可能有多少个出错的地方。
B：有风险，看你怎么看这个问题，最好个各系统给出各自的转换器，至于这个转换器是放在一个系统中还是各自系统中，那就看你看中沟通成本还是系统稳定性。如果一个转换器出问题，拥有者自己去改，那么影响的系统只是他那个系统。不过我们这个例子简单，其实放哪里都可以，问题不大。
C：你这样考虑吧，这个接口的返回其实和其他普通的json返回一样，虽然它有个正则属性在里面，就是普通的数据返回，其他系统想怎么用就怎么用呗。他是接口，那么必定不是只为了我们页面存在的。如果它是页面 那必须用js正则。
A: 对，使用者自己改又说明api不易用。
B：这个问题从不同的角度看都有一定道理，我都认可。
写在讨论后
A 后来提到的接口可用性确实是一个问题，当初我考虑的时候也忽略的了这个方面，如果是作为一个接口的消费者来说这个接口是不友好。如果要兼顾系统隔离，则应该传递一个中立的非指定语言的规则。不知道各位大神，各位看官怎么看这个问题？
网友评论