我正在构建一个发送流式XML的Web服务。所以，输出看起来（在高水平）像这样：
<fragment1>
<!-- ... -->
</fragment1>
<fragment2>
<!-- ... -->
</fragment2>
......等等。对于普通的XML文档，您可以使用以下任何一种不同的MIME类型：
但是，这些MIME类型都假定响应只包含一个XML文档/片段。在我的例子中，响应包含零个或多个片段。出于这个原因，使用其中一种MIME类型似乎是错误的事情。正确的处理程序将（正确地）将响应作为单个XML文档处理，并且（a）在到达第二个片段时处理barf，或者（b）默默地忽略从片段2开始的片段。
如果那是错误的东西，就是这些MIME类型之一The Right Thing：
application/octet-stream application/vnd.mycompany.com.description.streaming+xml application/vnd.mycompany.com.description+streaming-xml 或者我应该使用完全不同的？此外，如果数据格式联机后，可以将相同的MIME类型“样式”应用于流式JSON，那将会很棒。
编辑：为了给问题增加一些风格，并提供一个我正在尝试模拟的工作实现的示例，此API是在the Twitter streaming API之后建模的。
答案 0 :(得分：1)
除了您的流式传输要求之外，您的内容实际上是Multipart message，其中包含多个application/xml个部分。使用此布局application/json部分也可以在您的消息中混合使用。
如果您的个人XML片段是较大文档的一部分，请查看（有些陈旧且低调）XML Fragment Interchange W3C Candidate Recommendation。它定义了一个很好的语法来将片段主体与原始文档的上下文信息一起包装。
答案 1 :(得分：0)
根据数据中的语义关系及其结构，有多种选择。
第一个选项：如果您有一个（连续的）文件，可以通过将其包装在 <elem>…</elem> 标签中轻松地将其转换为有效的 XML 文档，则它应该application/xml-external-parsed-entity。这可以是从简单文本到注释、处理指令或复杂元素列表的任何内容。但是，您不能插入 XML 声明（必须通过 MIME 定义字符集）或任何 DTD（因此，如果您依赖 DTD，则其含义必须由封闭文档提供，并且您也不能包含任何其他外部解析实体，除非你使用 XInclude）。
我发现这适用于可以描述为任意 XML 内容/片段的任何内容。它主要用于通过 DTD 中的外部解析实体使用，但它本身也同样有效。如果您的片段可能没有单个根节点，请使用此选项。然而，我可以想到一个警告：如果流是无限的，客户端最终将不得不在某处终止它，并且由于没有指定外部边界，它可能会在元素的中间终止，根据到其架构。
您也可以使用 application/xml 并自己编写开始标记，但如果某些解析器配置为整体处理文档，则它们可能会等待文档结束。使用 application/xml-external-parsed-entity，最好的方法是将其解析为单个 XML 节点的流。
第二个选项：有 multipart 类型的范围。这样，您可以包装单个 XML 文档（application/xml 或特定的）或片段 (application/xml-external-parsed-entity)。同样，内部类型的选择取决于各个消息是否可以被视为独立的 XML 文档（例如 application/svg+xml 表示“SVG 视频”）。
子类型的选择取决于整个序列的预期含义。分组的单个独立文件流可以使用 multipart/mixed（这是最通用的类型）。如果 XML 数据以某种方式相互链接，您可以使用 multipart/related 并为各个片段分配标识符。最后，如果只有消息的最后一部分表示资源的最新内容（以保存单个请求），则使用 multipart/x-mixed-replace。
举例说明：
如果响应是包含 XHTML 标记的文本流（例如从 Markdown 流转换而来），则它应该是单个 application/xml-external-parsed-entity。
如果片段是附件、经常从网站下载或用户上传的文件，则应为multipart/mixed。
如果片段是大型或不断增长的资源图中的节点（不仅仅是 XML），则应使用 multipart/related。
如果结果是短暂的信息，例如某个过程的当前状态或对某事的持续测量，则它应该是 multipart/x-mixed-replace。