首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
宝塔
V2EX  ›  程序员

开发的表单需要同时提交给多个第三方系统,如何设计校验机制保持可用性和一致性

  •  
  •   myljs · 115 天前 · 1549 次点击
    这是一个创建于 115 天前的主题,其中的信息可能已经有所发展或是发生改变。

    以用户信息管理为例,用户在我们后台进行用户信息管理,但实际上背后我们会将这个用户信息同时更新到 A 系统、B 系统、C 系统进行存储和管理。

    但是不同的系统属于不同的公司,对于字段的校验规则或有不同,假设对于 firstName 字段:

    • A 系统的校验是大于 5 小于 30 个字符,不支持特殊字符
    • B 系统校验是大于 1 小于 50 个字符,特殊字符只支持 _
    • C 系统校验是大于 1 个字符,但是 name 不得是某些敏感单词

    对于这样的需求,我们需要如何设计我们的表单的校验规则?最安全的方式应该是取交集:**大于 5 小于 30 个字符,不支持特殊字符,不支持敏感单词。**但实际情况下,我们并不能知道第三方系统的具体校验规则(不会列在文档上),尤其是敏感单词列表更是不可能随意泄漏的规则。此外,第三方系统也可能会升级或者增减校验规则。

    然而对于我们,如果第三方系统校验失败,则用户的操作不会成功,就会产生一系列的问题:如何提示用户修改失败、清理脏数据或者重试提交等等。

    目前的思路:

    方案一:完全放开,只做最基础校验,透传数据和对应系统报错信息并反馈给用户。但这里的问题是第三方系统的报错反馈并不一定很友好,有时候虽然是因为 name 多了一个空格,结果 A 系统接口没做容错处理直接挂了返回 500。所以会导致用户比较懵,不知道哪里做错了然后联系客服处理,我们排查。此外部分接口是异步的 Job 去创建,如果失败还需要通过一个通知机制让用户再次登陆重试,比较麻烦。

    方案二:放弃,只设置基础规则,case by case 根据反馈加减校验规则,校验规则抽象放在一个地方方便统一修改。

    有没有其他的思路?

    19 回复  |  直到 2019-08-01 04:27:55 +08:00
        1
    leishi1313   115 天前
    建议你们辛苦点把所有能前端检测的校验都摸清楚然后融合在一起(长度,特殊字符等等),表单提交后再返回错误特别难受,特别是表单设计不好不能完全自动填充的情况,特别让人烦躁。敏感词这种本来就在后端校验的就不用自己再实现一遍了。
    但是最主要是,为什么人家系统的 api 给你们都不配文档的吗需要你们去这么猜?还是你们只是在做某种第三方聚合系统把人家 api 扒出来用了?那后续问题肯定还会有很多的毕竟人家的东西说改也不用通知你。
        2
    stanjia   115 天前
    没看完,感觉好复杂
        3
    xenme   115 天前 via iPhone
    新增一个三个字段,每个系统你们都根据规则生成一个新的符合对应规则的
        4
    orzorzorzorz   114 天前   ♥ 1
    恕我笨,针对这问题,我的思路也逃不出题主的这俩。在确定没什么好办法之后,我会去想另一个层面的事。
    一般这类问题都是去解决人的。如果是我,我一定会哭出声,然后求奶喝。既然你要做一个相对于 ABC 系统的第三方平台,那你只能付出更多的成本去定个能兼顾目前痛点的标准出来。
        5
    myljs   114 天前
    @leishi1313 一般文档都不会告诉你字段的具体校验规则是什么吧。题中其中一个系统就是 Microsoft 的 API,可以看下他们文档的内容 https://docs.microsoft.com/en-us/partner-center/develop/user-resources 只是告诉你有啥。
        6
    limuyan44   114 天前
    不给接口的第三方还是 3 家这不科学,你们这个不是非法的吧。。。
        7
    philipjf   114 天前
    如果是组织内部用的系统的话,最佳方案是统一创建分配用户名和显示昵称,后续让用户自行到各个系统修改对应的昵称。
        8
    Azmaveth   114 天前   ♥ 2
    @limuyan44 很多小贷的业务就是这样的,一个表单,信息发送给多处
    取交集的思路是对的但是容易导致业务进行不下去,用户体验不好
    我的建议是,按优先提交方效验规则进行检测,其余的信息(补齐)同步或者后台提交
        9
    liximomo   114 天前
    关于方案一所述的缺点“如果失败还需要通过一个通知机制让用户再次登陆重试,比较麻烦”,我认为这是个伪命题,因为接口总会有失败的可能,且造成失败的错误源也不仅仅只有字段校验一个,所有这个失败通知机制是不可避免的。
        10
    Sokiy   114 天前   ♥ 1
    无法确定校验规则,索性就前端不校验了或者一些必须的最大长度检验, 校验交给第三方系统去做

    自己在后端封装一层更新第三方系统的接口, 根据第三方系统需要的字段在后端维护一个可添加的「用户信息」(会随着第三方系统更新需要更新)

    然后用户输入完一个字段,输入框丢失焦点后去调用这个更新接口, 实时的返回字段校验结果

    用「用户输入的字段」替换掉「用户信息」里面的对应字段再去调用第三方系统的接口,然后根据第三方接口返回的提示信息自己封装用户提示(如果第三方接口返回的都是 the name is unavailable,那估计凉凉, 不知道校验规则的接口返回如果是这样的话,那都没辙吧)

    到最后提交的时候统一替换就行, 就起码用户用着不那么糟心吧,

    于大, 这样行不行?
        11
    Sokiy   114 天前
    @Sokiy 类似于先行模拟一个用户,根据用户的输入去更新模拟用户的信息, 用户取消操作就删除这个模拟用户
        12
    myljs   114 天前
    @limuyan44 三个系统都是正经 Saas 服务,给了接口,也有正规文档,但是文档不会告诉你某些字段背后具体的校验规则。
        13
    myljs   114 天前
    @Sokiy 谢谢,思路不错,就是成本偏大。而且已知的一个系统,账号只能创建不能删除(只能 deactivate )估计不行。

    @liximomo 其实失败通知机制是已经有的,但是一旦到了这一步,对用户就不够友好了,所以在想有没有尽可能好的优化方法。
        14
    wtks1   114 天前 via Android
    @leishi1313 之前遇到要对接一个系统,文档不给介绍没有,直接给了一个 jar 包让我们自己逆向解析一下....这才叫坑爹
        15
    leishi1313   114 天前 via Android
    @myljs 所以就看你们产品怎么考虑了,直接回第三方的错误一个问题就是格式内容都不一样了,我觉得还是把能想到的都先限制上
        16
    leishi1313   114 天前 via Android
    @wtks1 看源码有时候比文档快😂
        17
    CharlesWu   114 天前
    自己系统一个账户,对应到第三方的账户你们程序控制创建 然后绑定到自己系统上
        18
    itskingname   114 天前
    怀疑楼主可能做得是征信项目或者互联网金融项目或者保险项目。用户在你们自己的网站上登录,你把用户的信息通过爬虫登录另外的网站(例如支付宝、学信网、保险公司等等),获取征信内容。
        19
    myljs   114 天前
    @itskingname 脑洞真大。。。我在国外的一家云服务公司,国外基本啥都集成第三方系统,Billing 相关接 Zuora,客户管理接 Salesforce,云产品接 Microsoft Partner Center,还有其他小 Saas 服务不过依赖不多就不提了。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1328 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 00:02 · PVG 08:02 · LAX 16:02 · JFK 19:02
    ♥ Do have faith in what you're doing.