使用 application/json 优于 text/plain 的优势?

2022-01-15 00:00:00 json xmlhttprequest javascript httpwebrequest java

使用内容类型 application/json 通过 text/plain 发送序列化为 json 的对象是否有任何性能优势?

Is there any performance advantage of using content type application/json sending an object serialized to json over text/plain?

我知道许多框架(如 Spring)可以根据内容类型映射和序列化数据，但总的来说，我发现这个过程非常简单，因此使用 application/json<并不是一个令人信服的理由/code> 在 text/plain 上用于 JSON 对象.

I know many frameworks (like Spring) can map and serialize data based on the content type, but in general I find that this process is easy enough that it isn't a compelling reason to use application/json over text/plain for JSON objects.

例子:

xhr.setRequestHeader("Content-type","text/plain");
// or
xhr.setRequestHeader("Content-type","application/json");
xhr.send(JSON.stringify({"foo": "bar"}));

推荐答案

假设您正在讨论使用 JSON 与自定义格式(使用 MIME 类型 text/plain)来传递结构化数据.

Let's assume that you are talking about using JSON versus a custom format (using MIME type text/plain) for passing structured data.

性能可以分解为不同的组件；例如

Performance may be broken down into different components; e.g.

  • 将内容编码为格式所用的相对时间，
  • 解码格式以提供原始内容所需的相对时间，以及
  • 编码内容的相对大小.

理论上，我们可以说一个假设的优化设计和实现的自定义格式不会比 JSON 慢或密度不低.(证明"是显而易见的.选择 JSON 的最佳实现并对不影响性能的格式进行一些小的更改.)

In theory, we can say that a hypothetical optimally designed and implemented custom format will be no slower or no less dense than JSON. (The "proof" is obvious. Choose an optimal implementation of JSON and make some minor change to the format that doesn't affect performance.)

但实际上，您必须比较实际格式和实际实现的性能.因此，性能实际上取决于您在设计和实现格式及其相关的编码/解码软件方面做得如何.此外，它还取决于您如何实现 JSON.有许多具有不同性能特征的服务器端 JSON 库，以及将数据从/映射到本机"的不同方式.数据结构.

In reality though, you have to compare performance of actual formats and actual implementations. The answer therefore that the performance really depends on how good a job you do of designing and implementing the format and its associated encoding/decoding software. Furthermore, it also depends on how you implement JSON. There are a number of server-side JSON libraries with different performance characteristics, as well as different ways of mapping data from / to "native" data structures.

这让我们了解到 JSON(和 XML)相对于自定义格式的真正优势.

This brings us to the real advantages of JSON (and XML) over custom formats.

  • 借助 JSON 和 XML，您可以使用任何主流语言的库来协助编码和解码内容.使用自定义格式，您必须为客户端和服务器端滚动自己的编码/解码.

  • With JSON and XML, there are libraries available for any mainstream language you chose to use to assist in encoding and decoding content. With a custom format, you have to roll your own encoding / decoding for the client and server sides.

对于 JSON 和 XML，有一些标准说明什么是格式良好的，允许其他人实现编码器/解码器.使用自定义格式，如果您希望其他人能够实现您的格式，则必须自己编写规范.

With JSON and XML, there are standards that say what is well-formed that allow other people to implement encoders / decoders. With a custom format, you have to write the specification yourself if you want other people to be able to implement your format.

JSON 和 XML 具有处理字符集编码和元"等问题的标准方法.数据中出现的字符.对于习惯，您必须自己了解和解决这些问题.(如果你不这样做，你很可能会遇到困难.)

JSON and XML have standard ways of dealing with issues like charset encoding and "meta" characters appearing in data. With a custom you have to understand and address these issues your self. (And if you don't, you are likely to get into difficulty down the track.)

易于更改.演化基于 JSON/XML 的格式是一件相对简单的事情.但是使用自定义格式，您(至少)还有更多工作要做，而且根据您的设计选择，这可能会非常困难.

Ease of change. It is a relatively simple matter to evolve a JSON / XML based format. But with a custom format, you have (at least) got more work to do, and depending on your design choices, it could be very difficult.

对于大多数应用程序，这些问题远比性能更重要.这就是 JSON 或 XML 被广泛使用的原因.

For most application, these issues matter far more than performance. And that's why JSON or XML are widely used.

跟进

但是，如果您假设我没有使用自定义实现，并将发送带有 mime 类型 text/plain 的 JSON 与 mime 类型 application/json 进行比较，该怎么办?

But what if instead you assume that I'm not using a custom implementation and compare sending JSON with a mime type of text/plain to that of mime type application/json?

那么答案是它几乎没有 性能差异.

  • 您在 HTTP 请求或响应标头中节省了 6 个字节，因为 mime 类型字符串更短，但这对于大小以数千字节为单位的典型 HTTP 消息来说是微不足道的.
  • 使用text/plain"内容类型对编码/解码请求或响应消息所需的工作没有影响......除了比较/复制 6 个额外字节所花费的时间，这可能太小而无法衡量.

此外，使用不准确的 MIME 类型(可以说)违反了 HTTP 规范.如果你这样做:

In addition, using an inaccurate MIME type is (arguably) a violation of the HTTP specs. If you do this:

  • 接收方更有可能对响应处理不当；例如无法解码，或在浏览器窗口中显示，并且

  • it is more likely that the receiver will mishandle the response; e.g. fail to decode it, or show it in a browser window, and

假设您的客户端或服务器使用它，您可能会中断 HTTP 内容类型协商.

you may break HTTP content type negotiation, assuming that your client or server uses it.

简而言之，我想不出这样做的好理由1，以及不这样做的一些好理由.

In short, I can think of no good reason to do this1, and a few good reasons not to do it.

1 - 一般情况下.显然，会有边缘情况......

相关文章