Web 服务中序列化的成本

Question

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

大多数应用程序每次调用时只需要几个对象。然而，其他应用程序有时需要进行多次连续调用，每次调用涉及数千条记录。我担心的是表现。序列化/反序列化&我担心网络使用会出现瓶颈。如果每个请求都有很大的延迟，那么企业的所有应用都会变得迟缓。

我的恐惧是现实的吗？序列化为 XML 或 JSON 等大量格式会出现问题吗？还有其他选择吗？

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

我想提供三个指导方针：

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