如何评估 Web 服务框架 [关闭]

Posted 2023-02-22

【中文标题】如何评估 Web 服务框架 [关闭]

【英文标题】：How to evaluate a web service framework [closed]

【发布时间】：2016-07-14 23:16:34

【问题描述】：

我正在尝试评估不同的 Web 服务框架，以便在 .Net 中进行 API 开发。到目前为止，我一直在研究的框架是：

服务栈 MVC 网络 API NancyFx

我试图在框架之间找到一些共同的话题，这样我就知道在选择框架时要寻找什么。到目前为止，我得到的谈话要点是：

框架信念和原则 框架的架构（客户端和服务端） 框架为您提供的堆栈 堆栈内易于开发（插件等） 端到端性能基准 可扩展性基准 框架文档可用性 框架支持（跨平台等） 定价 总体结论

谁能想到我应该考虑的其他事情？在研究结束时，我希望详细介绍每个框架，并比较选择哪个框架给定的目的。任何帮助将不胜感激。

【参考方案1】：

端到端生产力 - 服务的核心本质是提供服务，最终为消费者带来一些价值。因此，消费服务的端到端生产力也应该被强烈考虑为从客户那里消费服务的难易程度和消费它们的最少努力，最终为客户提供了更多的价值，这通常比开发的生产力更有价值。服务本身，因为价值在其多个消费者中成倍增加。随着许多服务的不断发展，更新服务的开发工作流程以及确定更改内容的难易程度（即它们是否具有静态 API）也会影响客户端的工作效率。

互操作性 - 服务的另一个目标是互操作性以及从异构环境中使用服务的效果如何，大多数 Web 服务框架只是执行 HTTP，但在许多情况下，在 Intranet 环境中通过 MQ 发送 API 请求更合适，因为它提供了比 HTTP 更大的弹性、时间解耦、自然负载平衡、解耦端点、改进的消息传递工作流和错误恢复等。还有许多企业（和企业产品）仍然​​只支持或强制使用 SOAP，因此拥有 SOAP 端点并支持 XSD/WSDL 元数据也很有价值。

版本性 - 一些 API 设计自然更适合版本控制，在这种情况下，可以在不破坏现有服务使用者的情况下防御性地增强不断发展的服务。

可测试性和可模拟性 - 您还需要比较可以测试和模拟哪些服务的难易程度，以确定创建集成测试的难易程度以及它是否需要新的知识和基础架构以及它支持并行客户端开发的容易程度，这在前端和后端团队并行开发解决方案时很重要，其中可以在开发之前设计和商定服务的 API 合同，以确保在实施之前满足必要的要求，然后是前端后端团队可以相互独立地实施它们。如果服务尚未实现，客户端将需要“模拟”服务响应，直到它们实现，然后在它们实现后切换到使用真正的服务。

易学性 开发服务的直观程度、所需的认知和概念开销量也会影响生产力以及推理服务框架如何工作以及它的作用对您的影响的能力解决方案的整体复杂性和您的团队做出明智的实施决策的能力，这些决策会影响性能和可扩展性，以及让新开发人员学习您的解决方案所需的努力。