某跨境支付公司，专注于为中国跨境卖家提供低成本的跨境支付解决方案和定制金融服务。该公司业务遍及200多个国家和地区，是全球最大的跨境电商数字服务供应商之一。在全球设有多个分支机构，对于促进国际电子商务交易起着重要作用。他们为卖家提供跨境金融服务，同时需要在线上app上签署电子合同。
Docusign的嵌入式签署有着良好的客户体验，同时提供了极高的规范化和安全性要求，尤其是在客户数据处理和合规性方面。并且无论交易的数额庞大或普通，Docusign都提供了一致的信任和法律法规效力。这些都契合了该跨境支付公司的业务需求，故进行了引入使用。
随着跨境金融业务迅猛发展，他们引入了某外资商业银行进行合作，来提供更强大的后台服务，因他们在2022年就已经引入Docusign平台，并且使用反馈良好，故此次他们也推荐合作银行使用Docusign平台，用于此商业银行与他们的共同客户进行线上一站式签约。
在2022年时，这家跨境支付公司和Docusign的SDK进行集成时，有出现一个问题--JDK版本无法达到11，所以咨询了Support以后，得到以下答复：
经过公司内部讨论最终决定降级到Docusign版本。
根据业务需求，此商业银行公司最终也选择了Docusign的SDK集成方式，在测试过程中出现了一个NoSuchMethodError: org.glassfish.jersey.model.internal.CommonConfig.的错误。立刻咨询了Support，得到以下答复：
Support要求提供的资料繁琐并且来往信件时间花费很长，所以，我们直接开始排查这个问题。
首先排除客户下载的是否是Docusign完全依赖第三方的Shaded包。"Shaded" 在 Java 的上下文中通常指的是一种打包技术，用于创建包含项目所有依赖的 "uber-jar"（超级 jar 文件）。这种打包方式将项目的所有依赖项，包括所有必需的第三方库及其资源文件，全部打包到一个单独的 JAR 文件中。这样做的目的是为了避免类路径上的依赖冲突，简化部署流程，以及确保应用程序在运行时能够访问到其所有依赖。因为Shaded相对会比较大，所以第一时间确认了包的大小和版本。发现无错后，进一步去查看报错的报错栈。发现以下问题：
因为Docusign是基于jakarta的依赖，明明Shaded包里已经有，却没有引用到正确的版本，说明jar包冲突了，通过pom文件，依次发现两个包:
通过上图提示发现，jersey依赖的jakarta包与其公司的内部依赖jakarta包版本冲突，在考虑不影响其他项目，无法升级jakarta的前提下，给出两个建议：
1、降低Docusign的推荐版本
2、将SDK改成Rest API方式
为了方便客户全局考虑，我们针对这两种方式进行了对比，以帮助客户进行选择。
以下是SDK和REST API的使用体验比较：
1️⃣DocuSign SDK
定义: SDK是一组预打包的代码库和工具，旨在帮助开发者快速集成特定平台或服务。DocuSign SDK封装了对API的调用，提供了更简单的编程接口。优点:易用性: SDK通常包括示例代码、文档和其他资源，使得开发者更容易开始使用。快速开发: 由于SDK处理了很多底层细节，因此可以加速开发过程。更少的错误: 使用经过良好测试的SDK可以减少集成中的错误。缺点:灵活性有限: SDK可能不支持API的所有功能，限制了定制化的可能性。依赖性: 依赖特定的SDK可能会导致与特定语言或平台的强绑定。更新滞后: SDK的更新可能滞后于API的最新变化。
2️⃣DocuSign Rest API
定义: 建立不同软件应用程序之间的通信。DocuSign的Rest API允许直接与其服务进行交互，提供了更多的控制和灵活性。优点:灵活性和控制: 直接使用API可以访问所有的功能，允许更细致和定制化的集成。与技术更新同步: API通常会及时更新，反映出服务的最新变化。广泛的兼容性: API可以用于多种编程语言和平台。缺点:更复杂: 直接使用API可能需要更深入的技术知识和理解。开发时间更长: 需要手动处理更多细节，可能导致开发时间延长。错误风险更高: 直接与API交互增加了引入错误的可能性。
总之，选择SDK还是Rest API取决于你的具体需求、技术栈和资源。如果你需要快速开发和简化的集成流程，SDK可能是更好的选择。如果你需要更多的定制化和控制，直接使用API可能更合适。
需要特别强调的是：新版本（如4.5）通常包含在旧版本（如3.1）中不存在的附加功能、改进和错误修复。所以一旦以后出现错误或者是附加功能，都可能会被要求升级SDK来解决问题。另外DocuSign Support对于旧版本不提供技术支持。
