期待什么
目的是向开发人员展示在使用各种CRM系统的示例中其API用户面临的问题。
为了保护自己的脸，我不会在本文中刊登参与者的姓名。
另外，我-我不是母亲的女朋友的程序员，所以不要为唯一的选择而得出结论。
眼线笔
从前，有一个充满希望的男孩。 除了在会计程序的技术支持方面的工作外，这个男孩一生一无所有。 他在这个大锅里煮了很长时间，直到有一天，他从屋顶上撕下了，他寄出了宿主的主要特征并离开以寻找前景。
这个男孩一直梦想着自己将如何成为一名出色的开发商，他将赚取非凡的收入，最好以巴苏姆货币。 因此，在工作的同时，他使用前所未有的技术从事网站创建工作，但这些功能却是这些年来闻所未闻的。 因此，他得以找到一个新的所有者，给了他一份他最喜欢的业务的工作，他的薪水高，前景不切实际。
从那以后，这个男孩生活，生活并变得健康。 而且他不知道麻烦和悲伤...还是他知道？ 让我们弄清楚！
我在一家商业情报公司找到了工作。 而没有数据可以进行什么样的分析？ 因此，该公司有一个单独的团队，然后有一个部门负责从客户站点收集数据，以从广告渠道和其他来源建立收入明细表。 说到细节，我的工作是在站点上安装计数器，收集有关访客的数据，并从表单，在线聊天，回调等创建应用程序。 在他们的CRM系统中。 将来，我们的分析将收集其中有关销售状态和金额的信息。
似乎没有什么复杂的，因为CRM的应用程序的创建是通过包装我们的系统而简化的，该系统使用1个请求包装了应用程序和客户端，包括负责第三方服务的客户端。 但是，您应该了解，这种逻辑在灵活性上没有区别。 而且，如果客户需要一些非标准的东西，那么就已经有必要“关闭舒适模式”并卷起袖子直接使用所需系统的API。 有时，与下一个有问题的API一起使用时，
我认为最好留在其中。 支持 ...
问题＃1：缺少方法/数据
可能是我一生中遇到的最普遍的问题，就是缺乏获取接口中所需数据的能力。 由于我们每天都无法获得他们在监视器屏幕上看到的东西，因此与客户的冲突不断出现并继续发生。
例如，几年前，有一个相当大的客户来找我们，他需要保存客户从站点表单发送给他的CRM文件。 这是一项普通的任务，但是没有实现的可能性，而且至今没有！
客户端的失败是不可接受的，最后我们不得不上传文件，模拟来自接口的JS请求。
我必须说，这个CRM（API中的授权）也可以在接口中进行授权，对我而言，这是一个非常奇怪的解决方案。 但是，由于这个原因，我们不必模仿通常的授权。 还是，它是构思...？不久前发生了另一起使用相同CRM的案例。 必须对当前处于活动状态的应用程序经理负责。 正如您已经了解的那样，API不会将有关经理活动的信息返回给我们。 但矛盾的是他们的JS API返回了。 结果，我不得不编写一个JS应用程序，一种中介，此刻我通过该应用程序通知服务器有关活动管理器的信息。
解决方案：在我们的团队中，习惯上为接口创建公共API方法，并已通过该方法与服务器进行交互。 这消除了接口的技术功能与公共API之间不匹配的问题。
问题编号2：缺乏统一的请求/响应方式
即使在大型西方CRM中，这也是一个非常普遍的问题。 假设我们需要获取一个月的订单列表，我们发现系统对上载中的元素数量有限制。 要浏览页面，您需要使用offset参数。 好的，我们已经实现了加载订单的方法，并且分别实现了分页的辅助方法。
现在，我们需要卸载客户端列表，我们正在实现一个新方法以及之前编写的分页方法，并且... 我们得到一个错误。 因为PM和开发人员认为偏移听起来太简单了，所以现在让它变成vid-offset。
我当然夸大了，我不知道他们写这个api时发生了什么。 但这至少是一个PM错误，因为他没有指定其他方法中已经实现的方式。 还有开发人员，编写新方法的人员以及经过检查的人员的错误。 目前，使用API的每个人都必须在应用程序中构建拐杖。
解决方案：如果可能，任何新的api方法都应与现有的api方法相对应。 技术负责人（或缺少第一者的团队负责人）可以制定一种法规，一种代码风格，根据该规范，必须开发API，并且必须使所有开发人员都熟悉它。 如果问题已经存在，那么在可能的情况下，将拐杖放在您的身边比强迫成千上万的客户站在您的身边更好。
问题编号3：文档不良或缺乏
文档是开发人员参考。 当我们被问到实现特定功能的可能性时，我们经常会遇到一些情况。 如果我们不记得或不知道答案，请立即打开文档。 在一个好的目录中查找信息需要花费几分钟的时间，而在一个过载的目录中，您可以挖掘半小时，但仍然无法得到明确的答案。
在某些高级情况下，根本不可能在公共领域中找到。 而且，如果您需要获取最新的方法列表，则需要联系技术支持。 然后，您仍然需要检查那里是否有新东西出现，我们问了几个客户...
解决方案：对于我，我将提供一些表征质量文档的观点：
- 按名称，描述和方法参数搜索
- 正确描述方法的目的
- 带有类型和描述的可接受参数列表
- 带有类型和描述的返回参数列表
- 请求示例
- 回应范例
- 可能的错误代码及其说明
- 一个沙箱，您可以在其中以设计方式“处理”请求
- 更改所有api方法的历史记录以供快速参考
问题4：授权自行车
您会在打开新系统的文档时了解这种奇妙的感觉，在授权部分中，描述了3种方法的顺序，以获取仅对1个请求有效的密钥...？ 因此，我没有它。
对于我来说，仍然是一个谜，为什么开发人员放弃Oauth 2.0取而代之的是自行车？ 好的，如果授权仅限于一个常量令牌，但这是整个授权链...
解决方案：当已经有现成的标准时，您不应该重新发明您的自行车。 实际上，对于这些标准，开发人员已经具有用于简单授权的自己的组件。
结语
我谈到了到今天开始时遇到的4个问题。 我试图提供他们的解决方案，但是它们是否好由您决定。 最后，我们每个人都有自己的思想体系。
因此，我感谢所有到目前为止阅读的人！ 这是我的第一篇文章，如果对您有参考价值，那么我将很高兴继续阅读有关API遭受的痛苦的系列文章。
当然，我很高兴在评论中听到专家的意见。
即将到来的2020年！