似乎今天有两类API用于网站.
允许网站功能扩展的API,如Facebook,Myspace等.这些API似乎非常多样化.
API允许与Twitter,Flickr等现有网站功能进行交互.这些API都声称是基于REST的,但实际上只是"HTTP上的数据".
如果您正在创建允许功能扩展和外部交互的网站,那么您将使用哪些现有API作为参考模型？
我们自己正在这方面做一些研究.网站API参考的"黄金标准"方面并不多.
引用的最常见的网站API是:
Google API http://developers.google.com/api-client-library/java/apis
亚马逊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的高端网站)
如何设计一个好的API及其重要性,约书亚布洛赫 60分钟的谷歌技术讲话是相关的.
与一些人合作后,我会接受它
Facebook的
好的:干净且相对一致.表现很好,大多数事情在逻辑上都有意义.FQL非常整洁.XML和JSON选项.除了你真正需要的之外,没有预先设想的响应格式
坏:经常变化,没有警告.'官方'api库非常糟糕.许多电话的记录都很差或缺失.非标准认证(有些可能称之为好吗？)
我的空间
好的:开放标准(oAuth认证,Opensocial端点)
坏:经常坏了.oauth的使用是非标准的,并且打破了大多数客户端库.官方客户图书馆很糟糕.
Photobucket(免责声明:我写了photobucket api的服务器端)
好的:开放标准认证(oauth).xml,json,甚至php序列化数组格式作为响应参数.忠实的REST(获取/放置/删除/发布'名词'网址).
坏:客户端库不多.使用标准oauth库的架构挑战(用户居住在子域,必须调用子域,因此url必须更改).
推特
好的:相当一致(虽然api与搜索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上的一些东西,但我也讨厌一些.
在我看来,API 的文档与API的实际设计一样重要(或更重要).
写得很好,简单的文档将弥补任何设计缺陷.这是我在查看已发布的各种链接后所学到的.具体来说,Last.fm的文档似乎非常好:易于导航和易于理解.
Last.fm的api仍然是网上维护得最好的api之一.它也比大多数时间更长,因为它基本上就是这样.
http://www.last.fm/api
对于大的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.
京公网安备 11010802040832号 | 京ICP备19059560号-6 