3

我的下一个项目涉及在企业框架内创建数据 API。数据将由在不同软件平台上运行的多个应用程序使用。虽然我的同事普遍偏爱 SOAP，但我想使用 RESTful 架构。

大多数应用程序在每次调用时只需要几个对象。然而，其他应用程序有时需要进行多次顺序调用，每次调用都涉及数千条记录。我担心性能。序列化/反序列化和网络使用是我害怕找到瓶颈的地方。如果每个请求都涉及很大的延迟，那么企业的所有应用程序都会变得迟缓。

我的恐惧是现实的吗？将序列化为 XML 或 JSON 等大量格式会成为问题吗？有替代品吗？

过去，为了提高性能，我们不得不使用“更扁平”/更精简的文件格式（例如 CSV）来进行这些大型数据传输。我怎样才能希望使用 Web 服务获得所需的性能？

虽然我更喜欢特定于 REST 的回复，但我也有兴趣了解 SOAP 用户如何处理这个问题。

4

3 回答 3

2

REST 的一个优点是您可以自由使用您喜欢的任何媒体类型。为什么不继续使用 text/csv？您还可以启用 HTTP 压缩以进一步减少带宽消耗。

REST 服务非常适合利用所有不同类型的数据格式。无论哪种格式最适合您的场景。

于 2010-10-05T16:16:02.403 回答
1

我们提供 XML 和 JSON。您提到的渲染时间确实可能是一个问题。在服务器端，我们有 JAXB，它的标准 sun 实现在编组 XML 方面有点慢。XML 具有冗长的缺点，但在互操作性方面也很好，并且具有模式 + 显式版本控制。

我们以几种方式补偿了冗长（特别是限制结果集）：

  • 如果您有一个包含项目的容器，请在您的 xml 响应中提供分页（页面大小和页码，例如 /items?page=0&size=3）。客户端本身可以通过减小页面大小来减小大小。
  • 提供折叠元素，例如几个客户只对整个项目的一个数据字段感兴趣。使用参数（例如/items?select=name）执行此操作，然后只有嵌套元素'name' 包含在您的item 元素的内联中。这大大减小了尺寸。

通常赋予客户端使用结果集限制的权力。他们会明确地使用它，因为它也加快了他们的响应时间:)

也使用压缩，它极大地减少了冗长的 XML（在我们的例子中，有效负载小了 10 倍）。在客户端，您可以通过标题“Accept-Encoding: gzip”来完成。如果您使用 Apache，服务器配置也很简单

于 2010-10-05T17:36:25.643 回答
0

我想提供三个指导方针：

  1. 一是观察到有许多 SOAP Web 服务（尤其是使用 .NET 2.0“ASMX”技术构建的）发送以 XML 序列化的数据传输对象。当然，有许多 RESTful 服务会向下发送 XML 或 JSON。XML 序列化/反序列化很少是限制因素。
  2. Web 服务瓶颈的一个常见原因是一个接口，它鼓励客户端应用程序通过进行数千次顺序调用来获取数据（有一个术语：聊天接口）。这是您在设计 Web 服务界面时应该避免的，无论您决定使用哪种四字母缩写词。
  3. 关于 REST 要记住的一件事是它（部分）代表状态转移，这可能不适合某些您不想将业务对象的状态从服务器转移到客户端应用程序的操作。在这些情况下，SOAP Web 服务（如您的同事所建议的）更合适；或者可能是 SOAP 和 REST 服务的组合，其中 REST 服务将处理适合状态传输的操作，而 SOAP 服务将实现其余的操作（双关语意外:-)）。
于 2010-10-05T16:35:31.523 回答