什么是网站API的黄金标准？ Twitter，Flickr，Facebook等

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

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

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

如果您正在创build一个允许function扩展和外部交互的网站，那么您将使用哪些现有API作为参考模型？

Answer 1

我们正在这个领域做一些研究。 在网站API参考的“黄金标准”方面并不多。

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

• Google API http://developers.google.com/api-client-library/java/apis
• Amazon S3 http://docs.amazonwebservices.com/AmazonS3/latest/API/
• Twitter https://dev.twitter.com/
• Facebook http://developers.facebook.com/
• LinkedIn http://developer.linkedin.com/index.jspa
• 美味的http://delicious.com/help/api
• YouTube http://www.youtube.com/dev
• Netflix http://developer.netflix.com/
• Sun Cloud API http://kenai.com/projects/suncloudapis/pages/Home

这里另一个列表：

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

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

（请随意编辑上面的列表以添加其他具有API的高调网站）

Answer 2

如何devise一个好的API以及为什么它很重要 ，由Joshua Bloch进行的一个60分钟的Google技术讲座是相关的。

Answer 3

和几个人一起工作之后，我会马上下来

• Facebook的

  • 好：干净，相对一致。 performance良好，大部分事情在逻辑上是有道理的。 FQL非常整齐。 XML和JSON选项。 除了你真正需要的东西外，没有预先设定的回应格式
  • 坏的：经常改变而没有警告。 '官方'api图书馆是非常残酷的。 许多电话的logging很差或缺失。 非标准authentication（有人可能称这是好事？）

• 我的空间

  • GOOD：开放标准（oAuthauthentication，Opensocial端点）
  • 坏的：经常破裂。 oauth的使用非常不规范，打破了大多数客户端库。 官方客户端库很糟糕。

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

  • 好：开放标准authentication（oauth）。 XML，JSON，甚至PHP序列化数组格式作为响应参数。 忠实的REST（获取/放置/删除/张贴'名词'url）。
  • 不好：客户端库不多。 使用标准的oauth库（用户生活在子域名上，必须调用子域名，因此url必须改变）。

• 推特

  • 良好：相当一致（尽pipeAPI与searchAPI有差异）。 良好的REST实践。 OAuthauthentication以及支持oldschool Basic。
  • 坏的：错误率（几乎与其余的twitter一致）。 一些返回值的奇数格式（如他们的date格式）。

理想的特点

• 我不是在“严格的”REST上销售的。 PUT和DELETE在某些客户端语言中导致问题。 GET和POST似乎足以适当的“动词”。 另外，只要它们是逻辑的，甚至可以是URI的一部分，RPC类function名称对我来说也是可以的。 在这种情况下，对象IDS仍然需要非常一致。
• 标准authentication/授权。 基本/摘要可以，但是我是OpenID / oAuth的粉丝（或者如果你想变得更加stream畅，那么就是WRAP）。 滚动你自己意味着你必须解释它的100％，并可能为每个人写客户端库。
• 标准数据types。 确保你的数据types是一致的（“true”或1，而不是一些混合），并支持最通用的标准。 date时间应该是ISO8601。 地理定位应该看起来像GeoRSS等。你应该能够创build一个XSD / relaxNG /任何严格的validation器为您的返回types。 期望从您的input相同的标准。
• 简单的返回结构。 XML-RPC / JSON-RPC有一些好处，那就是你知道你回来了什么，但是无论如何，如果我不能用JSON或类似PHP的SimpleXML轻松地parsing你的返回types，并且基本上把它序列化到一致哈希，我会生气。
• 支持扩展/扩展而不破损。 不要将自己编码到一个angular落，并很难添加到您的API。 试着做出正确的决定，你不会经常改变。
• 文档！ 确保它的好，并解释一切。 即使那样也不够好，所以要确保你有足够的时间来开展工作，并有一个支持论坛或者其他方法来保持它的最新状态。

所以说… Facebook和Twitter之间的东西。 当然，我对Photobucket上的一些东西有所偏爱，但我也讨厌其中的一些东西。

Answer 4

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

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

Answer 5

Last.fm的API仍然是networking上保持最好的API之一。 它也比大多数时间长，因为它基本上就是这样开始的。

http://www.last.fm/api

Answer 6

关于杰夫的大API名单：我很确定， 共同的并不意味着“黄金标准” 。

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

因为我喜欢REST作为松散的标准，所以我认为当一个API 合理且直观时，API是“黄金”。

• Twitter（ http://apiwiki.twitter.com/ ），
• Github（ http://develop.github.com/ ）和
• Last.FM（ http://www.last.fm/api ）

……对我来说都是最有意义的，并且经过深思熟虑（就像Brian已经指出的那样）。

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

如果你喜欢它是严格和安全的，使用SOAP。

Answer 7

我会检查OpenSocial，这是一个为社交networking创buildAPI标准的运动。 他们为此使用REST，并采用“用户”为中心的方法。 但这是一个非常有据可查的方法，甚至可以帮助一个不完全基于社交的网站。 如果你正在寻找一些内部代码实现看看Drupals钩子系统和Wordpress。

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

Answer 8

我认为最好的回答方法是列举好的web API的特性 ，而不是举例。 如果你喜欢Twitter / Facebook / etc API，你觉得这些API有哪些方面有吸引力？

我会先试一下：

1. logging良好的API，包括约束和使用策略。 这使得信心十足的快速发展，而不是第二次猜测什么参数可能意味着什么，返回值是什么。
2. 技术/语言不可知的API。 良好的API应该易于使用，在各种语言和平台上提供相同的function。
3. 支持良好的API。 总是有错误。 响应式维护人员可以获得更多可用的API
4. 分层的API集。 当API整齐地分层时，广泛的开发者可以消费他们需要的部分，而不需要拉入无关的层。 作为一个优点，它迫使创作者认真思考清洁和组件化的API。

请添加更多的评论。

Answer 9

我没有任何与其他人的经验，但即使这些年来发展，Facebook API仍然是可怕的。 它不会接近任何“金标准”。 相反，这是人们通过磨合的方式，因为一旦它们最终得到正确的结果，它可以增加很多价值。

Answer 10

一些非常好的API：

• Last.FM http://www.last.fm/api （精彩文档）
• Github http://develop.github.com/ （高兴地工作，深思熟虑）

Answer 11

这将取决于你的目标受众是什么。 如果是.net商店，那么肥皂可能是另一个明智的关注REST，因为它有一个低得多的条目。 从那里看看针对你想要的同一个人的网站API。 这样你的API会觉得很熟悉。

Answer 12

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

Answer 13

AtomPub是黄金标准，因为它是由互联网上一些最聪明的人devise的。 使用iit作为基础，你不能犯太多错误。 这是谷歌和MSFT的。

Answer 14

有一个类似的问题，这没有得到太多的行动，但认为这将是很好的链接到它。

你最想要复制什么Web API或者最受欢迎？

Answer 15

如果我现在正在为一个现有的网站devise一个web api，假设这个网站在正确使用HTTP的过程中devise得很好，我将使用现有的网站作为devise指南 。

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

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

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

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

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

编写完善的网站对于networking浏览器客户端来说已经是非常有效的API了，实际上没有必要回到绘图板来支持任何其他types的客户端。 API结构不需要改变，只是交付的内容。