我们目前正在为应用程序计划一个新的" API"，并讨论用于交换的各种数据格式。关于" CSV"，" JSON"和" XML"的相对优点的讨论非常激烈。

基本上，该论点的症结在于，由于缺乏递归，我们是否应该完全支持CSV(即，具有"多个作者"和"多个引用"的文档将需要"多个API调用"来获取所有信息)。

在使用" Web API"中的信息时，我们可能会遇到的经验以及我们可以做的事情，使使用" API"的开发人员的工作更加轻松。

我们的决定：

We've decided to provide XML and JSON due to the difficulty in recursion in CSV needing multiple calls for a single logical operation. JSON doesn't have a parser in Qt and Protocol Buffers doesn't seem to have a non-alpha PHP implementation so they are out for the moment too but will probably be supported eventually.

解决方案

CSV是正确的。 JSON是一种比XML更紧凑的对象表示法，因此，如果我们正在寻找大量的对象，则它具有优势。 XML具有更广泛的市场渗透率(我喜欢这个短语)，并且得到所有编程语言及其核心框架的支持。 JSON正在到达那里(如果尚未到达那里)。

就个人而言，我喜欢括号。我敢打赌，与json相比，更多的开发人员更喜欢使用xml数据。

CSV作为复杂的数据模型有很多问题，我不会使用它。
XML非常灵活，并且易于与客户端一起编程，不会对XML生成器和解析器进行编码，我们甚至可以使用SAX提供示例解析器。

我们是否签出了Google的网络数据格式？它称为协议缓冲区。不知道它是否对REST服务有用，因为它也跳过了整个HTTP层。

XML有时可能会有些重量级。 JSON非常好，但是具有良好的语言支持，并且可以将JSON数据直接转换为许多播放表单上的本机对象。

好处：

• XML-许多库，开发人员都熟悉它，XSLT，可以轻松地通过客户端和服务器(XSD，DTD)，分层数据进行验证
• JSON-易于在客户端解释，紧凑的表示法，分层数据
• CSV-在Excel中打开(？)

缺点：

• XML-膨胀，在JavaScript中比JSON更难解释
• JSON-如果使用不当会造成安全漏洞(请勿使用eval)，并非所有语言都有库来解释它。
• CSV-不支持分层数据，我们将是唯一这样做的人，它实际上比大多数开发人员认为解析有效的csv文件要困难得多(CSV值可以包含新行，只要它们位于引号之间，等等)。

鉴于以上所述，我什至都不会支持CSV。如果确实需要，客户端可以从XML或者JSON生成它。

我对JSON没有任何经验，当数据非常表格化且结构均匀时，CSV可以发挥作用。 XML很快就会变得笨拙，尤其是在我们没有自动创建与对象的绑定的工具的情况下。

我也没有尝试过，但是Google的协议缓冲区看起来非常好，格式简单，创建了对C ++，Java和Python的自动绑定，并实现了所创建对象的序列化和反序列化。