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

Question

似乎今天网站有两类API。

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

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

如果您正在创建允许功能扩展和外部交互的网站，那么您将使用哪些现有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

How To Design A Good API and Why it Matters，Joshua Bloch的60分钟Google技术讲座，是相关的。

Answer 3

与一些人一起工作后，我会直接了解它

• 实

  • GOOD：干净且相对一致。表现很好，大多数事情在逻辑上都有意义。 FQL非常整洁。 XML和JSON选项。除了你真正需要的之外，没有预先设想的响应格式
  • 坏：经常变化，没有警告。 '官方'api库非常糟糕。许多电话的记录都很差或缺失。非标准认证（有些可能称之为好吗？）

• 的Myspace

  • GOOD：开放标准（oAuth身份验证，Opensocial端点）
  • 坏：经常坏了。 oauth的使用是非标准的，并且打破了大多数客户端库。官方客户图书馆很糟糕。

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

  • GOOD：开放标准身份验证（oauth）。 xml，json，甚至php序列化数组格式作为响应参数。忠实的REST（获取/放置/删除/发布'名词'网址）。
  • 不好：客户端库不多。使用标准oauth库的架构挑战（用户居住在子域，必须调用子域，因此url必须更改）。

• 微博

  • GOOD：非常一致（虽然api vs search api有差异）。良好的REST实践。 OAuth身份验证以及支持oldschool Basic。
  • 坏：错误率（尽管与其他人的推特非常一致）。某些返回值的奇怪格式（如日期格式）。

理想特征

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

所以说... Facebook和Twitter之间的东西。当然我偏爱我们在Photobucket上的一些东西，但我也很讨厌它。

Answer 4

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

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

Answer 5

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

http://www.last.fm/api

Answer 6

关于杰夫的大型API列表：我非常确定常见 不意味着“黄金标准”。

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

由于我喜欢REST作为松散标准，我认为当有意义且直观时，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，这是一个为社交网络sice创建API标准的运动。他们使用REST进行此操作并采用“以用户为中心”的方法。但这是一个非常有文档记录的方法，甚至可能有助于一个不完全基于社交的网站。如果您正在寻找一些内部代码实现，请查看Drupals钩子系统和Wordpress。

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

Answer 8

我认为最好的方法是列出优秀网络API的特性，而不是引用示例。如果您喜欢Twitter / Facebook / etc API，那么您觉得这些API的哪些方面很有吸引力？

我会第一次刺伤：

1. 记录良好的API，包括约束和使用策略。这样可以放心地快速开发，而不是再次猜测参数可能意味着什么，以及返回值是什么。
2. 技术/语言无关的API。良好的API应该易于使用，在各种语言和平台上提供相同的功能。
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

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

Answer 13

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

Answer 14

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

What web APIs would you most want to replicate or are the most popular?

Answer 15

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

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

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

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

设计网络API与设计网站没什么区别，除了您提供的内容将由非网络浏览器的程序使用。

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

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