这是一个创建于 1950 天前的主题，其中的信息可能已经有所发展或是发生改变。
以用户信息管理为例，用户在我们后台进行用户信息管理，但实际上背后我们会将这个用户信息同时更新到 A 系统、B 系统、C 系统进行存储和管理。
但是不同的系统属于不同的公司，对于字段的校验规则或有不同，假设对于 firstName 字段：
- A 系统的校验是大于 5 小于 30 个字符，不支持特殊字符
- B 系统校验是大于 1 小于 50 个字符，特殊字符只支持 _
- C 系统校验是大于 1 个字符，但是 name 不得是某些敏感单词
对于这样的需求，我们需要如何设计我们的表单的校验规则？最安全的方式应该是取交集：**大于 5 小于 30 个字符，不支持特殊字符，不支持敏感单词。**但实际情况下，我们并不能知道第三方系统的具体校验规则（不会列在文档上），尤其是敏感单词列表更是不可能随意泄漏的规则。此外，第三方系统也可能会升级或者增减校验规则。
然而对于我们，如果第三方系统校验失败，则用户的操作不会成功，就会产生一系列的问题：如何提示用户修改失败、清理脏数据或者重试提交等等。
目前的思路：
方案一：完全放开，只做最基础校验，透传数据和对应系统报错信息并反馈给用户。但这里的问题是第三方系统的报错反馈并不一定很友好，有时候虽然是因为 name 多了一个空格，结果 A 系统接口没做容错处理直接挂了返回 500。所以会导致用户比较懵，不知道哪里做错了然后联系客服处理，我们排查。此外部分接口是异步的 Job 去创建，如果失败还需要通过一个通知机制让用户再次登陆重试，比较麻烦。
方案二：放弃，只设置基础规则，case by case 根据反馈加减校验规则，校验规则抽象放在一个地方方便统一修改。
有没有其他的思路？
 |
1
leishi1313 2019-07-31 07:04:31 +08:00
建议你们辛苦点把所有能前端检测的校验都摸清楚然后融合在一起（长度，特殊字符等等），表单提交后再返回错误特别难受，特别是表单设计不好不能完全自动填充的情况，特别让人烦躁。敏感词这种本来就在后端校验的就不用自己再实现一遍了。
但是最主要是，为什么人家系统的 api 给你们都不配文档的吗需要你们去这么猜？还是你们只是在做某种第三方聚合系统把人家 api 扒出来用了？那后续问题肯定还会有很多的毕竟人家的东西说改也不用通知你。 |
 |
2
stanjia 2019-07-31 07:20:35 +08:00
没看完，感觉好复杂
|
 |
3
xenme 2019-07-31 07:27:44 +08:00 via iPhone
新增一个三个字段，每个系统你们都根据规则生成一个新的符合对应规则的
|
 |
4
orzorzorzorz 2019-07-31 08:30:27 +08:00  1
恕我笨，针对这问题，我的思路也逃不出题主的这俩。在确定没什么好办法之后，我会去想另一个层面的事。
一般这类问题都是去解决人的。如果是我，我一定会哭出声，然后求奶喝。既然你要做一个相对于 ABC 系统的第三方平台，那你只能付出更多的成本去定个能兼顾目前痛点的标准出来。 |
 |
5
myljs OP @leishi1313 一般文档都不会告诉你字段的具体校验规则是什么吧。题中其中一个系统就是 Microsoft 的 API，可以看下他们文档的内容 https://docs.microsoft.com/en-us/partner-center/develop/user-resources 只是告诉你有啥。
|
 |
6
limuyan44 2019-07-31 09:04:06 +08:00
不给接口的第三方还是 3 家这不科学，你们这个不是非法的吧。。。
|
 |
7
philipjf 2019-07-31 09:29:17 +08:00
如果是组织内部用的系统的话，最佳方案是统一创建分配用户名和显示昵称，后续让用户自行到各个系统修改对应的昵称。
|
 |
8
Azmaveth 2019-07-31 09:42:41 +08:00 2
@limuyan44 很多小贷的业务就是这样的，一个表单，信息发送给多处
取交集的思路是对的但是容易导致业务进行不下去，用户体验不好 我的建议是，按优先提交方效验规则进行检测，其余的信息（补齐）同步或者后台提交 |
 |
9
liximomo 2019-07-31 10:41:50 +08:00
关于方案一所述的缺点“如果失败还需要通过一个通知机制让用户再次登陆重试，比较麻烦”，我认为这是个伪命题，因为接口总会有失败的可能，且造成失败的错误源也不仅仅只有字段校验一个，所有这个失败通知机制是不可避免的。
|
 |
10
Sokiy 2019-07-31 11:21:20 +08:00 1
无法确定校验规则,索性就前端不校验了或者一些必须的最大长度检验, 校验交给第三方系统去做
自己在后端封装一层更新第三方系统的接口, 根据第三方系统需要的字段在后端维护一个可添加的「用户信息」(会随着第三方系统更新需要更新) 然后用户输入完一个字段,输入框丢失焦点后去调用这个更新接口, 实时的返回字段校验结果 用「用户输入的字段」替换掉「用户信息」里面的对应字段再去调用第三方系统的接口,然后根据第三方接口返回的提示信息自己封装用户提示(如果第三方接口返回的都是 the name is unavailable,那估计凉凉, 不知道校验规则的接口返回如果是这样的话,那都没辙吧) 到最后提交的时候统一替换就行, 就起码用户用着不那么糟心吧, 于大, 这样行不行? |
|
12
myljs OP @limuyan44 三个系统都是正经 Saas 服务，给了接口，也有正规文档，但是文档不会告诉你某些字段背后具体的校验规则。
|
|
13
myljs OP |
 |
14
wtks1 2019-07-31 12:03:44 +08:00 via Android
@leishi1313 之前遇到要对接一个系统，文档不给介绍没有，直接给了一个 jar 包让我们自己逆向解析一下....这才叫坑爹
|
|
15
leishi1313 2019-07-31 12:11:53 +08:00 via Android
@myljs 所以就看你们产品怎么考虑了，直接回第三方的错误一个问题就是格式内容都不一样了，我觉得还是把能想到的都先限制上
|
|
16
leishi1313 2019-07-31 12:12:31 +08:00 via Android
@wtks1 看源码有时候比文档快😂
|
 |
17
CharlesWu 2019-07-31 12:22:56 +08:00
自己系统一个账户，对应到第三方的账户你们程序控制创建 然后绑定到自己系统上
|
 |
18
itskingname 2019-07-31 12:30:05 +08:00
怀疑楼主可能做得是征信项目或者互联网金融项目或者保险项目。用户在你们自己的网站上登录，你把用户的信息通过爬虫登录另外的网站（例如支付宝、学信网、保险公司等等），获取征信内容。
|
|
19
myljs OP @itskingname 脑洞真大。。。我在国外的一家云服务公司，国外基本啥都集成第三方系统，Billing 相关接 Zuora，客户管理接 Salesforce，云产品接 Microsoft Partner Center，还有其他小 Saas 服务不过依赖不多就不提了。
|
Select Language