“对象网络”：用于Web API的数据链接

     <div id="news_body">     <p> 作者 <a href="/misc/goto?guid=4958333925837587122">Jeevak Kasarkod</a> 译者 <a href="/misc/goto?guid=4958333926634135944">高翌翔</a></p>     <p> 当您努力学习新的 Web API 时感到不堪重负了吗？您是否觉得花费了大量精力用于处理不兼容的数据格式，而这些格式来自于不同 Web API 的同一对象？<a href="/misc/goto?guid=4958333927425177037">ThoughtWorks</a> 公司的 <a href="/misc/goto?guid=4958333928210253707">Duncan Cragg</a> 正在致力于一个名为“ <a href="/misc/goto?guid=4958333928997384617">对象网络（Object Network）</a>” 的项目，该项目旨在通过通用数据定义和访问格式来消除这类学习曲线，并且最重要的是，通过建立全球链接数据基础结构来放大网络效应。InfoQ 采访了 Duncan Cragg，从而揭示付出这些努力的深层动机和原因，还有 API 开发者应如何将 API 发布到此数据网络、以及如何从中提取数据。</p>     <p> <strong>InfoQ：对象网络（Object Network）是什么？</strong></p>     <blockquote>      <p>尽管这个概念几乎简单得显而易见，并且一经提出便无懈可击，然而或许没人相信它真的有可能实现：</p>      <p><em>并非 ProgrammableWeb 网站上列出那些迥然不同、互不兼容的<a href="/misc/goto?guid=4958333929785486216" target="_blank">4000多个 API</a>，为什么不能只用一种方式来公开来自这些网站和服务的数据呢？</em></p>      <p>如果 推ter、非死book、Flickr 和 Google 都有用户和照片，那么为什么要用 4 种不同的方法去访问它们、而且是以 4 种互不兼容格式？只定义一种方法、及单一的格式，因此我们只需编写一个客户端库，而不是 4 个、更不是 4000 个！</p>      <p>尽管 API 的增长引人瞩目：一幅急剧上升的图形。但是与之相比，<a href="/misc/goto?guid=4958333930572873519" target="_blank">20世纪 90 年代的网站增长</a>则是爆炸式的！如果我们能够对一些基本的、简单协议和格式达成一致，那么我相信，在“数据网络” 中，我们在 API 方面同样能够实现类似的飞速增长。我们需要一种“适用于 API 的 HTML”——一些有关检索 JSON 的约定和一些有关 JSON 形式的预期——这真的很简单！</p>      <p>这正是<a href="/misc/goto?guid=4958333931383302209" target="_blank">对象网络（Object Network）</a>登台亮相之际。</p>      <p>在对象网络中发布 API 只需遵守简单的规范，包括<a href="/misc/goto?guid=4958333932171989340" target="_blank">有关 HTTP 和 JSON 的基本约定</a>，以及用于通用数据的任意数量的格式，包括联系信息、日历事件、新闻、文章和消息源、媒体元数据、评论和回复、产品等。</p>      <p>按照这些模式，您网站中的数据可以加入全球互联的“数据数据基础结构（data fabric）”。在您的网站问世之前，那些已存在的客户或客户代码就可以访问到您的数据。</p>     </blockquote>     <p> <strong>InfoQ：为何需要对象网络（Object Network）？</strong></p>     <blockquote>      <p>那么问题在于，每个 API 都是不同的、而且需要不同的位于 HTTP 之上的协议进行通讯，还需要针对不同的 JSON 响应分别解析。但是我们总是力争在这个行业中通过共享代码和通用标准来减少低效。</p>      <p>作为服务端开发者，发布到对象网络（Object Network）以后，通过共享客户端代码及网站间的互联可以扩展您的数据范围。您也无需花费大量时间来设计您的接口，因为当您来实现它时所有的协议约定和格式都将整理成册。或者您可以与其他人一起定义适用于特殊情况和领域的新的对象网络（Object Network）格式。毫无疑问，还将会出现一些框架，从而将现存的和新的数据便捷地发布到对象网络（Object Network）中。</p>      <p>作为使用对象网络（Object Network）接口的客户端开发者，您可以复用通用客户端代码，例如对获取链接和缓存数据的处理、转换为基本的 HTML 等诸如此类的代码。您还将理解一些通用数据类型（common data types），并且可以提供一些顶层的实用功能，例如把若干联系人对象绘制在一张地图上。最后但同样重要的是，再多的数据也将仅有一种链接方式，且允许跨站点导航和数据消费。</p>     </blockquote>     <p> <strong>InfoQ：什么是在语义网（Semantic Web）或链接数据（Linked Data）标准、或者 REST 的超媒体约束中所没有的，而在对象网络（Object Network）提供了？</strong></p>     <blockquote>      <p>大多数开发者（包括我在内）没有时间或耐心去学习或从事任何看起来过于复杂或需要太多投入的事情！我认为正是语义网（Semantic Web<sup>[1]</sup>）或链接数据（Linked Data<sup>[2]</sup>）、还有更加奇特的 REST 中的诸多模式、解释和参数吓跑了开发者。</p>      <p>大体上，据我所知，一般的 API 开发者并不认为 RDF<sup>[3]</sup>非常适合于发布他们的数据。而 RSS 1.0<sup>[4]</sup>不过是其中的数据点。JSON-LD<sup>[5]</sup>可能是朝着正确方向的一个开始，但是我认为它仍被视为受累于过多的语义网包袱。它好像也没有设置任何与 HTTP 用法或 REST 风格应用程序有关的约定。此外，似乎没有任何与数据更新有关的内容。</p>      <p>同样，我看不出有任何证据表明，一般的 API 开发者会非常重视修正 REST。如果正确实现 REST 被认为是如此容易，那么所有所谓的“REST API”其实<em>是</em>REST 风格的！</p>      <p>开发者需要更简单的工作模式：一种可以让他们的生活变得更简单的模式，并通过一种适用于数据的通用语言来提供语义网带来的全部好处，此外，还能提供 REST 带来的全部好处，即互操作性（interoperability）和可扩展性（scalability）——“ 可混合性（mashability）和可缓存性（cacheability）”。</p>      <p>大多数人都说不出，如何以简单的 JSON 形式来发布语义网的链接数据，或者如何满足每一个 REST 约束，从而通过自描述（Self-descriptiveness）来实现从无状态（Statelessness）到超媒体（Hypermedia）的转变。</p>      <p>然而，我只需短短几行代码就能展示，如何使用简单的 JSON 模板将您的数据发布到对象网络（Object Network）中、如何在对象之间获取超链接、以及在您的 HTTP 消息中需要放些什么。而且数据更新是对象网络（Object Network）语言的一部分。</p>      <p>其他人可能会争论，对象网络（Object Network）是否是真正的 REST 风格，或者与链接数据相比是更好还是更差——我认为答案显而易见，分别是“是”和“更好”！我就想让人们谈论、共享、并交付它。将数据交付到互联的动态数据全球网络。</p>      <p>显然，不但是许多语义网和链接数据源，而且还有它们使用的词汇，二者都极具价值。二者皆可复用并重新发布到对象网络（Object Network）中，作为庞大的静态数据和对象类型语义来使用。应该有种相当自动的转换，从而实现从 rdf+xml 资源到链接对象网络（Object Network）JSON 的转换。</p>      <p>同样，所谓的“REST API”——全部 4000 多个 API——提供了巨大而富饶的实用数据矿藏，它们都可以被简单修改，从而融入对象网络（Object Network）之中，可能会使用某些工具来完成，例如 <a href="/misc/goto?guid=4958333932954614355" target="_blank">ql.io</a>。</p>     </blockquote>     <p> <strong>InfoQ：对于对象编程模型与对象网络（Object Network）中数据模型之间存在的阻抗失衡（impedance mismatch），您打算如何弥合？</strong></p>     <blockquote>      <p>我认为这对于分布式系统而言大部分都是可接受的，当您的“分布单元”是不错的数据块，而不是进程、过程或方法调用的时候工作效果最佳。同样，当您执行的不是同步以及位于脆弱的同步锁下地操作，而是异步、无状态、且等幂<sup>[6]</sup>地操作时，事态会更易于管理。</p>      <p>因此我认为任何人都不会过多地抱怨我没在对象网络（Object Network）中为那些对象公布 RMI<sup>[7]</sup>（远程方法调用）接口！</p>      <p>对象网络（Object Network）中的“对象（Object）”一词实际上源于 JSON 中的字母“O”：实际上，它就是一个序列化的哈希表。所以它看起来可能更像是 JSON DTO<sup>[8]</sup>，不过其具有严格的格式或类型结构、URL、可链接到其他对象的内容、以及可更改的内容。</p>      <p>我把对象网络（Object Network）中的对象视为一些由各自服务器“绘制”出来的具有公共状态的对象。</p>      <p>理想状况下，它们应通过状态依赖来工作——就像电子表格：“这个对象的状态依赖于那个对象的状态”。我已发表了一些有关此编程模型的细节——我称之为“Functional Observer”（功能观察者）或“FOREST”——就在“<a href="/misc/goto?guid=4958333933759885530" target="_blank">REST: From Research to Practice</a>”（REST：从研究到实践）这本书的某一章中（参见 <a href="/misc/goto?guid=4958333934552792377" target="_blank">http://forest-roa.org</a>——请注意，在那些早期资料中我曾把它称之为“Object Web”）。</p>      <p>但是，整个那部分内容都不是必须的：在对象网络（Object Network）接口之后，您可以用任何喜欢的方式来绘制您自己的对象。我之所以首先重点解释那些最简单的模式——是因为只有先学走才能再学跑（学习更高级内容）！</p>     </blockquote>     <p> <strong>InfoQ：对象网络（Object Network）的目前进展状况如何？接下来有何打算？</strong></p>     <blockquote>      <p>迄今为止，主要涉及一些 ThoughtWorks 的客户和同事，不过我看到外界对<a href="/misc/goto?guid=4958333931383302209" target="_blank">当前的对象网络（Object Network） 博文系列</a>的兴趣颇多。我也经常做讲座和写文章来解释这些想法——总之我会抓住任何机会来解释这些想法！（虽然历经数次更名，但是现在已步入正轨，从今以后我将称之为“对象网络（Object Network）”。）</p>      <p>我在 GitHub 上有些 Javascript 代码（必须要进行更新）实现了浏览器客户端——即对象网络（Object Network）查看器。您可以使用它通过链接对象进行导航、获取投票变化或刷新。它也了解不同的对象类型，因此可以提供那些类似在地图上查看联系人的功能。该计划还将提供一个 Javascript 库，以便当客户端应用程序使用对象网络（Object Network）的数据时重用该库。它也应该可与 Node.js 结合运行在服务器上，用于普通页面的装配。</p>      <p>进一步看，我在 GitHub 还有一个称为“NetMash”的 Java 代码库，其中有 Android 对象网络（Object Network）查看器和服务器。目前来看，那些内容在很大程度上具有实现性：具有更多有关异步和双向数据更新的高级功能。</p>     </blockquote>     <p> <strong>InfoQ：一个人如何才能参与到对象网络（Object Network）项目中？</strong></p>     <blockquote>      <p>必须做的有：(1) <a href="/misc/goto?guid=4958333936081187949" target="_blank">加入此 Google Group</a>，还有 (2) <a href="/misc/goto?guid=4958333931383302209" target="_blank">跟随此此系列博文</a>，正如它所写的那样！</p>      <p>然后就是发布！其实很简单——您可以把简单的 JSON 模板和您现有的 Web 栈一起使用，或者甚至发布若干静态或预生成的 JSON 文件。正如我所说，我们需要发布的第一份数据是已经可用的、且具有较少的可访问形式。我们将继续致力于一些服务端框架或类库支持，毫无疑问，发布将变得更轻松。</p>      <p>那么我们就可以在 JavaScript 查看器中查看这一切，或者您可以开始编写基于 JavaScript 库代码的特色应用——当然要等到一切准备就绪时。当然，您完全可以使用您的 Javascript 专家级技能与我一起编写那些代码。</p>     </blockquote>     <p> <strong>译注</strong></p>     <p> [1] <strong>Semantic Web</strong>，即语义网。语义网是一个由万维网联盟的蒂姆·伯纳斯-李（Tim Berners-Lee）在 1998 年提出的概念，其核心是：通过给万维网上的文档（如：HTML）添加能够被计算机所理解的语义（Meta data），从而使整个互联网成为一个通用的信息交换媒介。语义万维网通过使用标准、标记语言和相关的处理工具来扩展万维网的能力。不过语义网概念实际上是基于很多现有技术的（某些技术甚至可以追溯到 20 世纪 60 年代末期），也依赖于后来和 text-and-markup 与知识表现的综合。<a href="/misc/goto?guid=4958333937593298102">维基百科</a>。</p>     <p> [2] <strong>Linked Data</strong>，即链接数据。在计算领域中，链接数据描述了一种发布结构化数据的方法，以便链接数据可以互联进而变得更加有用。它建立在 HTTP 和 URI 等标准的 Web 技术之上，但不是使用它们来为人类读者的网页服务，而是它以一种可由计算机自动读取的方式来为共享信息提供数据。这样就可以连接和查询来自不同源的数据。更多内容请参阅<a href="/misc/goto?guid=4958333938388688055">维基百科</a>。</p>     <p> [3] <strong>RDF</strong>，即资源描述框架（Resource Description Framework），是万维网联盟（W3C）提出的一组标记语言的技术标准，以便更为丰富地描述和表达网络资源的内容与结构。更多内容请参阅<a href="/misc/goto?guid=4958333939178579974">维基百科</a>。</p>     <p> [4] <strong>RSS 1.0</strong>，即 RDF 网摘（RDF Site Summary）或简易资讯聚合，是一种消息来源格式规范，用以发布经常更新资料的网站，例如 blog 文章、新闻、音讯或视讯的网摘。RSS 文件（或称做摘要、网络摘要、或频道）包含了全文或是节录的文字，还有发布日期和作者身份等元数据。更多内容请参阅<a href="/misc/goto?guid=4958333939967764865">维基百科</a>。</p>     <p> [5] <strong>JSON-LD </strong>，即<strong>J</strong>ava<strong>S</strong>cript <strong>O</strong>bject <strong>N</strong>otation for <strong>L</strong>inked <strong>D</strong>ata，是一种使用 JSON 来传输链接数据的方法，它旨在使用得到广泛支持的 JSON 序列化格式来存储和传输链接数据。更多内容请参阅<a href="/misc/goto?guid=4958333940766974685">维基百科</a>。</p>     <p> [6] <strong>等幂</strong>（idempotent），指同一消息（函数）可重复执行两次或多次，而执行结果保持不变的性质。</p>     <p> [7] <strong>RMI</strong>（Remote Method Invocation），即远程方法调用，更多内容请参阅<a href="/misc/goto?guid=4958193989496908968">维基百科</a>。</p>     <p> [8] <strong>JSON DTO</strong>（JSON Data Transfer Object），即 JSON 数据传输对象。</p>     <p><strong> 查看英文原文：</strong><a href="/misc/goto?guid=4958333942292533620">"The Object Network": Data Linking for Web APIs</a></p>    </div>