​

这是spring的第2篇原创

我们先来了解一下什么是API。

百度词条里面是这样解释的：

API（Application Programming Interface，应用程序接口）是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。 [1]  用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

而通俗的讲就是我给你一定的限制条件，你通过我的条件匹配对应的数据传给我。

背景

在匹配物流产品规则不成功时，需配置相应的提示语返回给用户

物流商返回的错误信息中，需匹配对应的提示语返回给用户

物流商返回的错误信息无法判断是否返回给用户时，需要将信息展示在“交运异常”页面，待物流商人工判断

目标

正确地把需要用户处理的异常提示信息返回给用户

对于不能成功交运的订单需要物流商进一步处理

调研

用户手动选择需要提交的包裹时，调取物流系统的渠道列表，展示可用的渠道，不可用的渠道提示不可用的原因，该原因在配置匹配规则时相应的配置提示语。这时是调用自家系统配置的规则，因此不会有物流商返回的关于匹配规则不符的情况的提示语

用户选择渠道后，将包裹信息回传给WMS

WMS打印面单调物流商的面单接口时，通常会出现物流商返回的错误信息，此时仓库的人员告知技术进行处理线上问题

流程图如下：

以下三个方案是一个思考的过程，最终选择的是第三个方案。

01

方案一如下：

商户提交包裹订单时调用产品列表接口（包含物流商的面单接口），如果是规则不匹配则把需要客户处理的信息返回给客户，如果是系统原因返回到SCM物流模块给物流商处理

客户异常信息的维护：物流商返回的信息与提示进行匹配

异常信息的维护：物流商需定时处理异常信息，如果是需要客户处理则标注原因，并把该信息录入“客户异常信息”页面维护

流程图如下：

02

方案二如下：

结合以上调研结果，取长补短，输出最新建议方案

前提：所有的匹配规则判断是在SCM的物流模块配置的，物流商不会通过接口提供规则

在配置物流产品规则时同时配置不能使用该物流产品的原因，该原因用于提示用户

相较于方案一，不需要维护客户异常信息，且凡是物流商返回的错误信息则展示在交运异常页面待物流商处理

流程图如下：

如下配置规则时同时配置禁用该渠道的原因原型案例：

03

这是一个最终的方案：

既需要在配置规则时同时配置不可用的提示语，也要有一份客户异常信息维护的表

流程图如下：

总结

为什么调研的那个方案可以做到准确的把不可用的提示语给到用户呢？

因为本身系统把物流商对渠道的所有规则都做到自己的系统里，对匹配的规则有一个可控的范围

而出现方案三这样的复杂情况，是因为系统本身没有把渠道的规则都做了设置，而是调的物流商的下单接口来校验商品的情况；除此之外，物流商的服务器有些是部署在国外的，也会存在调用接口的不稳定性

方案三本身也存在一定的问题，上线后有用户进来使用之后再进行迭代，到时再输出一篇文章来进一步说明

在产品设计中，你知道哪些异常问题，你是怎么解决的呢？