如何评估web服务框架

我试图评估不同的web服务框架，以便在.Net中开发API。到目前为止，我一直在研究的框架包括：

• ServiceStack
• MVC
• Web API
• 南茜

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

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

---

有人能想出我应该考虑的其他事情吗？在研究结束时，我希望详细地写下每个框架，并对为特定目的选择的框架进行比较。任何帮助都将不胜感激。

端到端生产力-服务的核心要素是提供一项最终为其消费者提供某种价值的服务。因此，消费服务的端到端生产率也应被视为客户消费服务的便利性和消费服务的最少努力，最终为客户提供更多价值，这通常比开发服务本身的生产力更有价值，因为价值在其多个消费者之间成倍增加。随着许多服务的不断发展，更新服务的开发工作流以及确定更改内容的容易程度（即，如果它们具有静态API）也会影响客户端的生产率

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

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

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

可学习性开发服务是多么直观，所需的认知和概念开销也会影响生产率和推理服务框架如何工作的能力，以及它所做的工作会影响解决方案的总体复杂性和团队做出影响性能和可伸缩性的明智实施决策的能力，以及实现这些决策所需的努力让新开发人员了解您的解决方案