SOAP/REST Web 服务 - 基础设施和最佳实践答案

【问题标题】：SOAP/REST Web Services - Infrastructure & Best PracticesSOAP/REST Web 服务 - 基础设施和最佳实践
【发布时间】：2014-01-04 13:27:30
【问题描述】：

我的第一份工作/职责是从头开始设计和实现 Web 服务（java、spring），以供外部系统（其他公司）使用。我对这个机会感到兴奋，但同时由于这是我的第一次尝试，我想确保我尽我所能...... 我确信随着设计的发展，我必须考虑以下几点： 1. 可扩展性和最小延迟 2. SLA 遵守（例如端到端 2 秒） 3. 支持不同的媒体类型（SOAP、POX、JSON）

我们目前正处于定义合同的阶段，在此过程中，我想确保除了我可以处理自己的应用程序级别细节之外，我还应该能够考虑基础设施方面的挑战（服务器、可扩展性等）。

如果您可以根据过去的经验回答或指出一些可以帮助我前进的资源，我期待在这方面获得一些帮助。

附： :- 我已经了解与安全相关的因素、在 wsdl 中定义策略以及其他应用程序级别的考虑因素。我主要关心的是基础架构级别的选择和决策。

谢谢！

【问题讨论】：

标签： web-services jax-ws jax-rs spring-ws infrastructure

【解决方案1】：

祝贺你的新任务！他们必须考虑很多，才能给你这么大的责任。

至于您的问题，我认为 Web 服务 API 就像传统的 Web 应用程序一样。唯一的区别是你的客户很可能是代码而不是人。因此，您已经知道的所有相同的 Web 应用程序可伸缩性原则——Web 服务器的负载平衡、在数据库上构建索引和视图、缓存——在这里同样适用。你不应该有任何不同的想法。同样，请确保使用 JMeter 或商业产品进行性能测试是您持续集成基础架构的一部分。

至于支持不同的媒体类型，我不明白你的意思。既然您提到了 Spring，Spring 和 Spring Web Services 将涵盖您快速入门所需的一切。您需要解决许多 API 级别的问题，例如身份验证、授权、日志记录、审计、错误处理等。有很多资源可以回答您的具体问题。

有一件事我也可以说。请注意耦合。您的 WSDL 和 REST API 肯定会发生很大的变化。确保您以这样一种方式编码，即这些更改不会影响您的代码库的其余部分。或者你会在一个小改动后花费很多周末来解决所有问题。

祝你的项目好运！

【讨论】：

谢谢你，维迪亚。这有帮助。我所说的“支持不同的媒体类型”是指支持不同类型的消息格式（如 SOAP、POX、JSON）的同一个 Web 服务。这在 Web 服务领域更正式地称为“媒体类型协商”。
另外，您能否介绍一下应用服务器的选择？我们选择哪个应用服务器真的很重要吗？作为我们现在的小公司，我们主要依赖开源的东西。所以，我们一直在使用 JBOSS、ActiveMQ 等。我想知道当我们最终变得更大并且我们的 Web 服务的容量更大时，使用相同的解决方案是否会有任何限制，或者我们是否应该考虑使用许可的应用程序服务器和IBM、Oracle 等的消息传递框架。
我已经做了很多来支持不同的媒体类型，但我从来没有听说过“媒体类型协商”这个词哈哈。这很花哨。这也很简单。借助 REST，可以将服务配置为根据 Content-Type 和 Accept 标头自动区分。
开源很好。事实上，我会选择 JBoss 等作为我的堆栈，同时根据需要向 RedHat 支付支持费用。
我认为您不能将 SOAP 和 REST 结合在一个内容协商应用程序中。以我的经验，SOAP 和 REST 是（可悲的）两个不同的东西。你可以使用带有内容协商视图解析器的 Spring-MVC 在 JSON、XML 之间切换（对于 REST），无论你喜欢什么。例如，基于 URL 中的文件扩展名。对于 SOAP，您可以使用 Spring-WS。