61

今天的网站似乎有两类 API。

  1. 允许扩展站点功能的 API，如 Facebook、Myspace 等。这些 API 似乎非常多样化。

  2. 允许与现有站点功能（如 Twitter、Flickr 等）交互的 API。这些都声称是基于 REST 的，但实际上只是“HTTP 上的数据”。

如果您正在创建一个允许功能扩展和外部交互的网站，您会使用哪些现有 API 作为参考模型？

4

15 回答 15

37

我们自己也在这方面做一些研究。网站 API 参考的“黄金标准”并不多。

引用的最常见的网站 API 是：

这里的另一个列表：

http://www.pingable.org/the-top-15-web-apis-for-your-site/

有人推荐这本书Restful Web Services作为这方面的一个很好的参考。

（请随时编辑以上列表以添加其他具有 API 的知名网站）

于 2010-02-05T06:31:58.863 回答
23

Joshua Bloch的 60 分钟 Google 技术演讲How To Design A Good API and Why it Matters 与此相关。

于 2010-02-05T07:00:29.330 回答
16

和几个人一起工作过，我会开始做的

  • Facebook

    • 好：干净且相对一致。表现良好，大多数事情在逻辑上都是有意义的。FQL 非常简洁。XML 和 JSON 选项。除了您真正需要的之外，没有对响应格式的预先概念
    • 坏：经常改变，没有警告。“官方” api 库非常糟糕。许多电话的文档很差或丢失。非标准身份验证（有些人可能称之为好？）

  • 我的空间

    • 好：开放标准（oAuth 身份验证、Opensocial 端点）
    • BAD：经常坏。oauth 的使用非常不标准，并且会破坏大多数客户端库。官方客户端库很糟糕。

  • Photobucket（免责声明：我编写了 photobucket api 的服务器端）

    • GOOD：开放标准认证（oauth）。xml、json、甚至php序列化数组格式作为响应参数。忠实的 REST（在“名词”网址上获取/放置/删除/发布）。
    • 不好：客户端库不多。标准 oauth 库的架构挑战（用户生活在子域中，必须对子域进行调用，因此 url 必须更改）。

  • 推特

    • 好：非常一致（尽管 api 与搜索 api 有差异）。良好的 REST 实践。OAuth 身份验证以及支持 oldschool Basic。
    • 坏：错误率（不过与推特的其他部分几乎一致）。一些返回值的奇怪格式（如它们的日期格式）。

理想特性

  • 我不是在“严格”的 REST 上出售的。PUT 和 DELETE 会导致某些客户端语言出现问题。使用适当的“动词”，GET 和 POST 似乎就足够了。此外，类似 RPC 的函数名称对我来说是可以的，只要它们是合乎逻辑的，甚至可能是 URI 的一部分。在这种情况下，对象 IDS 仍然需要非常一致。
  • 标准认证/授权。Basic/Digest 可以，但我是 OpenID/oAuth 的粉丝（或者如果你想获得最前沿的 WRAP）。滚动你自己意味着你必须解释 100%，并可能为每个人编写客户端库。
  • 标准数据类型。确保您的数据类型保持一致（“真”或 1，而不是混合），并支持最通用的标准。日期时间应为 ISO8601。地理位置应该“看起来像”GeoRSS 等。您应该能够为您的返回类型创建一个 XSD/relaxNG/任何严格的验证器。期望您的输入具有相同的标准。
  • 简单的回报结构。XML-RPC/JSON-RPC 有一些好处，因为你有点知道你得到了什么，但无论如何，如果我不能用 JSON 或 PHP 的 SimpleXML 之类的东西轻松解析你的返回类型，并且基本上将它序列化为一致哈希，我要生气了。
  • 支持无破损扩展/扩展。不要将自己编码到一个角落，并使其难以添加到您的 API。试着预先做出好的决定，你不会经常改变。
  • 文档！确保它是好的，并解释一切。即使那样它也不够好，所以请确保您有专门的时间来处理它，并有一个支持论坛或其他任何东西来保持它的最新状态。

话虽这么说...... Facebook和Twitter之间的东西。当然，我偏爱我们在 Photobucket 上的一些东西，但我也讨厌其中的一些。

于 2010-02-05T15:48:59.337 回答
11

在我看来， API的文档与 API 的实际设计一样（或更多）重要。

写得好，简单的文档将弥补任何设计缺陷。这就是我在查看已经发布的各种链接后所学到的。具体来说，Last.fm 的文档看起来非常好：易于浏览且易于理解。

于 2010-02-05T08:42:13.447 回答
8

关于 Jeff 的大 API 列表：我很确定common 并不意味着“黄金标准”。

无需保留广泛 API 的手动列表。要获取列表，请查看http://www.programmableweb.com/apis/directory/1?sort=mashups。

由于我喜欢将 REST 作为松散的标准，我会说 API 在有意义且直观时是“黄金” 。

……所有这些对我来说都是最有意义的，并且经过深思熟虑（正如布赖恩已经指出的那样）。

在我目前的日常工作中，我也经常使用 OpenSocial，其中 URI 感觉非常自然，但也以自己的方式扩展了 REST 标准。

如果您喜欢它严格和安全，请使用 SOAP。

于 2010-02-05T07:51:15.337 回答
8

Last.fm 的 api 仍然是网络上维护得最好的 api 之一。它的存在时间也比大多数都长，因为它基本上就是这样开始的。

http://www.last.fm/api

于 2010-02-05T06:41:32.943 回答
4

我会查看 OpenSocial，这是一项为社交网络创建 API 标准的运动。他们为此使用 REST，并采用以“用户”为中心的方法。但这是一个非常有据可查的方法，即使是不完全基于社交的网站也可能有所帮助。如果您正在寻找一些内部代码实现，请查看 Drupals 挂钩系统和 Wordpress。

http://code.google.com/apis/opensocial/

于 2008-11-17T21:32:44.393 回答
3

我认为最好的回答方式是列出好的 Web API 的特征，而不是引用示例。如果您喜欢 Twitter/Facebook/etc API，您觉得这些 API 的哪些方面有吸引力？

我将采取第一刺：

  1. 有据可查的 API，包括约束和使用策略。这样可以放心地进行快速开发，而不是再次猜测参数可能意味着什么，以及返回值是什么。
  2. 与技术/语言无关的 API。好的 API 应该易于使用，提供相同的功能，跨多种语言和平台。
  3. 支持良好的 API。总是有错误。响应式维护者带来更多可用的 API
  4. 分层 API 集。当 API 被整齐地分层时，广泛的开发人员可以使用他们需要的部分，而无需引入无关的层。另外，它迫使创建者认真思考干净和组件化的 API。

请在评论中添加更多内容。

于 2010-02-05T10:30:00.290 回答
2

我对其他人没有任何经验，但即使经过多年的发展，Facebook API 仍然很糟糕。它远非“黄金标准”。相反，这是人们努力克服并咬紧牙关的事情，因为一旦他们最终做对了，它可以增加很多价值。

于 2009-12-28T18:25:17.457 回答
2

一些特别好的 API：

于 2010-02-05T06:43:59.510 回答
1

这将取决于您的目标受众是什么。如果是.net 商店，那么soap 可能还可以，否则明智地专注于REST，因为它的进入门槛要低得多。从那里查看针对您想要的相同人群的网站 API。这样你的 api 会感觉很熟悉。

于 2008-11-17T21:57:40.007 回答
0

有一个与此类似的问题，但没有采取太多行动，但认为链接到它会很好。

您最想复制或最受欢迎的 Web API 是什么？

于 2010-02-06T01:57:42.043 回答
0

如果我今天为现有网站设计 Web api，假设网站在正确使用 HTTP 方面设计得很好，我会使用现有网站作为设计指南。

以 Stack Overflow 为例，它已经将整个 URI 空间映射出来。它在不同的表示之间定义了一套完整的互连。该站点的用户已经熟悉站点结构，因此 API 结构已经很熟悉。

唯一需要更改的部分是表示的内容，以消除所有不必要的标记。有必要添加一些额外的模板链接，以允许当前只能通过 javascript 访问的搜索。例如，搜索用户不容易通过导航发现，因为当前链接是通过 javascript 构建的。

真正棘手的决定是使用什么媒体类型。您可以使用带有 RDFa 样式元数据标记的简单 html，或者在 Html5 中使用新的 Microdata 格式。或者，您可以返回基于 xml 或 Json 的自定义媒体类型。像 application/vnd.stackoverflow.question+xml 等。自定义媒体类型使版本控制变得非常容易，但对于不是设计为直接访问 StackOverflow 的客户端来说，它不太容易访问。自定义类型可以与 StackOverflow 中大部分已经存在的 Atom 提要结合使用，

设计一个 web api 与设计一个网站实际上没有什么不同，除了你提供的内容将被一个不是 web 浏览器的程序使用。

您不想做的是创建一个基于 Http 的数据访问层。这就像向世界展示你的内衣一样。现有网站针对所有常见使用场景进行了优化，许多 api 访问模式将是相似的，因此重用已经创建的“视图”。可能有必要在这里和那里添加一些额外的链接，以使程序更快地获取所需的数据，但是可以根据需要逐步添加这些链接。

编写良好的网站已经是 Web 浏览器客户端非常有效的 API，实际上没有必要回到绘图板来支持任何其他类型的客户端。API 结构不需要改变，只需要改变交付的内容。

于 2010-02-08T04:06:01.647 回答
0

AtomPub 是黄金标准，因为它是由互联网上一些最聪明的人设计的。使用 iit 作为基础，你不会走得太远。这就是 google 和 msft 所做的。

于 2010-02-05T17:08:24.400 回答
0

Force（以前称为 SalesForce）API： http: //www.salesforce.com/us/developer/docs/api/index.htm

于 2010-02-05T09:39:30.070 回答