Posts Tagged ‘API’

部分网站的Api地址 转 月光博客

星期四, 04月 15th, 2010

之前也搜集过部分网站的Api地址,不过月光blog做的不错。特此转告~!!@#¥

月光博客 [ http://www.williamlong.info/

所谓的开放API(OpenAPI)是服务型网站常见的一种应用,网站的服务商将自己的网站服务封装成一系列API(Application Programming Interface,应用编程接口)开放出去,供第三方开发者使用,这种行为就叫做开放网站的API,所开放的API就被称作OpenAPI(开放API)。

  网站提供开放平台的API后,可以吸引一些第三方的开发人员在该平台上开发商业应用,平台提供商可以获得更多的流量与市场份额,第三方开发者不需要庞大的硬件与技术投资就可以轻松快捷的创业,从而达到双赢的目的,开放API是大平台发展、共享的途径,让开发者开发一个有价值应用,付出的成本更少,成功的机会更多。今天,OpenAPI作为互联网在线服务的发展基础,已经成为越来越多互联网企业发展服务的必然选择。下面我就列举一些常见网站服务的Open API文档资源索引。

  SNS类网站API

  Facebook - http://developers.facebook.com/

  人人网开放平台 - http://dev.renren.com/

  51.com开放平台 - http://developers.51.com/

  MySpace开发者平台 - http://developer.myspace.cn/

  Opensocial - http://wiki.opensocial.org/

  Google Gadgets 小工具 API 开发人员指南 - http://www.google.com/intl/zh-TW/apis/gadgets/docs-home.html

  Gadgets API 开发人员指南 - http://code.google.com/intl/zh-CN/apis/gadgets/docs/dev_guide.html

  Gadgets API - http://code.google.com/intl/zh-CN/apis/gadgets/

  电子商务类

  Amazon API - http://aws.amazon.com/

  eBay API - http://developer.ebay.com/

  淘宝开放平台 - http://www.taobao.com/theme/tao_source/

  微博API

  Twitter API - http://apiwiki.twitter.com/Twitter-API-Documentation

  Status.Net(Laconica) API - http://status.net/wiki/Twitter-compatible_API

  新浪微博开发者平台 - http://open.t.sina.com.cn

  注:需要授权的开发者才能访问,其API调用格式类似Twitter,但需要一个API Key用于认证管理。

  搜狐博客开放平台 - http://ow.blog.sohu.com/

  Follow5 API - http://www.follow5.com/f5/jsp/other/api/api.jsp

  嘀咕API - http://code.google.com/p/digu-api/wiki/DiguApi

  做啥API - http://code.google.com/p/zuosa-api/wiki/ZuosaApiDoc

  人间网API - http://renjian.com/api.html

  9911微博API - http://www.9911.com/api.php

  Google Maps API

  Google Maps API Developer Guide - http://code.google.com/intl/en/apis/maps/documentation/

  Google Maps API Tutorial - http://econym.org.uk/gmap/extensions.htm

  GMaps Utility Library - http://code.google.com/p/gmaps-utility-library-dev/wiki/Libraries

  GMaps Utility Examples - http://gmaps-utility-library.googlecode.com/svn/trunk/labeledmarker/release/examples/

  Saving User-Added Form Data - http://code.google.com/intl/zh-CN/apis/maps/articles/phpsqlinfo.html

  Firefox类

  Mozilla 开发者中心的扩展开发专题 - https://developer.mozilla.org/en/Extensions

  XUL 1.0 规范 - http://www-archive.mozilla.org/projects/xul/xul.html

  更多地了解这种基于 XML 的用户界面语言,它可以构建各种富跨平台应用程序。

  Mozilla Development Center 的 XUL 教程 - http://developer.mozilla.org/en/docs/XUL_Tutorial

  Getting started with extension development 编写一个最简单的Firefox扩展 - http://kb.mozillazine.org/Getting_started_with_extension_development

  Setting up extension development environment - http://developer.mozilla.org/en/docs/Setting_up_extension_development_environment

  实战 Firefox 扩展开发 - http://www.ibm.com/developerworks/cn/web/wa-lo-firefox-ext/

  使用 XUL 实现浏览器扩展 (1) - http://www.ibm.com/developerworks/cn/web/wa-xul1/

  使用 XUL 实现浏览器扩展 (2) - http://www.ibm.com/developerworks/cn/web/wa-xul2/

  应用类

  豆瓣API - http://www.douban.com/service/apidoc/

  Flickr API - http://www.flickr.com/services/api/

  Last.fm API - http://www.last.fm/api

  Box.net API - http://developers.box.net/

  Delicious API - http://delicious.com/help/api

  API统计 - http://www.programmableweb.com/apis

【转】打造自己的Twitter 和 Search API Proxy 为了gravity 或者~~

星期五, 11月 20th, 2009

由于不少朋友很少涉及所以还是失败了,毕竟安装Python 和 Google App Engine SKD的方法对于从未接触的朋友还是有些太困难了,以下方法可以通过一个简单的第三方上传软件SDUpload避免再安装复杂的Python 和 Google App Engine SKD:

一、申请Appspot账号。

1、注册app engine,地址 http://appengine.google.com/ ,有google account很方便的就建立了。

2、建立一个application,如图:

(注,建立过程会验证你的手机号码)

3、给自己的application设置一个唯一的id,以后就可以用yourid.appspot.com来访问你的app。

网上这三步就完成了,它的作用其实就是在Appspot申请一个账号.

下面就是要在本机的电脑修改要上传的源码并上传.

二、下载源码并修改为自己对应的账号。

4、直接下载本贴打包的nest.rar(见附件,这个Nest更改过源码,支持建立搜索API)

5、解压到某个目录,比如 X:\nest

6、用称手的编辑器或是记事本打开app.yaml这个文件,把第一行application: userid的userid改成你自己刚才建立的id。

三、上传修改后的nest文件到Appspot账号。

7、关键从这里开始,大家将下载附件SDUpload 0.1.rar(见附件)解压到任意位置即可,如X:\sdupload,

8、随后将刚才修改过的Nest文件夹拷入这个sdupload文件夹.

9、然后”开始”-”运行”,输入cmd.exe进入命令行状态,在通过DOS命令进入sdupload文件夹

(先进入X:盘, DOS命令是X: ,

再进入sdupload目录,DOS命令是 cd sdupload )

此时电脑的显示应该是:x:\sdupload,再输入以下命令行即可:

SDUpload update nest

10、此时,会提示你输入你的email地址和密码。输入你申请Appspot对应的就OK了。如果出错误提示,请多试几次。我在试用时,没有关闭Freedur就出错过。注意,输入密码时,电脑是不显示的,但请回车即可。

一切搞定,非常简单!

注意,Gravity 1.20 6000版本,已经完美支持这个自建的API,全功能。

建立了这个API后,在你的gravity里设置api代理时不要再写后面的/api/了,只要写 userid.appspot.com 就可以了。(替换userid为你自己申请的ID)

原文地址:http://bbs.ifanr.com/viewthread.php?tid=2046&

SDUpload 和 nest的下载地址请到原文地址下载~~~~

sidewiki让google向“老大哥”在进一步?

星期四, 09月 24th, 2009

Google在今天发布了一个全新产品:Google Sidewiki,将允许任何用户在任何网站发表评论。用户也可以在Sidewiki发表自己的见解,提供更多相关主题的内容以便其他用户查看参考。

当然Sidewiki也提供了通过Twitter,Facebook等快速分享评论的功能。

不同于传统的思路,Sidewiki并不是把最新的评论显示在最上方,而是通过特定算法把Google认为最有用,质量最高的评论优先显示。参考的内容则包括其他用户对这条评论的评价以及这条评论作者以前的表现等因素。

要使用Google Sidewiki的话,用户需要安装新版的支持Sidewiki的Google Toolbar(这意味着Chrome暂时无缘这个功能,当然Google提到了将尽快提供对Chrome等浏览器的支持)。

Google还提供了Sidewiki API的首个版本,同时开放了@googlesidewiki这个Twitter帐号。

有一个互联网深度用户的工具出炉。

共享数据给google,会不会最终导致被“老大哥”监视?

API设计

星期二, 04月 28th, 2009

Michi Henning同样在文中也给出了他的一些如何让API更加优秀的建议:

  ·API必须要提供充分的功能,以供调用者完成自己的任务。

  ·API应该是最精简的,不要为调用者带来多余的不便。

  ·如果没有理解API的使用环境的话,那也就不能去设计它。

  ·通用性的API应当是与具体使用场景无关的,而特定用途的API则要充分考虑使用策略。

  ·API应该从调用者的角度来进行设计。

  ·好的API绝不推卸责任,把自己该做的事情留给别人。

  ·在实现API之前,就应该把API文档化。

  ·好的API应当符合工效学(Ergonomic)。

Is Twitter Strangling its Famous API?

星期六, 01月 24th, 2009

The most extreme developers may find themselves left out in the cold.

Twitter watchers know that a large part of the service’s use comes through its Application Programming Interface (API) and that’s been a big part of what helped the young service grow. Now that the company has Britney Spears, CNN and Barack Obama among its ranks of users, though, developers seeking to push the limits of that API may soon find themselves no longer welcome.

Last night Twitter announced on its developer email list that API calls from a single IP will be limited to 20,000 per hour. Desktop clients and services seeking only status updates won’t be affected, only services pinging Twitter over and over again for information like users’ friends lists or other relatively unsupported data types will likely run up against the limit.

No More “I Dislike You Too” Lists

What does that mean? For now it means that a handful of services that notify users who has unfollowed them will be effectively non-viable. That’s far from our only concern about the issue, however.

Readers may remember a service called Qwitter, which emailed you every time someone unfollowed you on Twitter and told you what your last message posted was before that happened. On October 25th, a 15 year old UK blogger named “Joel D.” stopped following me after I tweeted about being tired in ceramics class, for example. I don’t hold a grudge but if you’ve got something against ceramics, Joel, then I say good riddance to you!

Seriously, though, a veil of paranoia and petty bitterness lifted from all of Twitter-dom just before Christmas when Qwitter finally gave up the ghost due to scalability issues on its end. (Apparently some people are still getting messages.) Update: Qwitter’s founder dropped by to tell us that the service is now back up. So head on over, masochists of Twitter.

Now a service called SocialToo has raised the alarm about the forthcoming limit and says that a similar feature it offers will disappear as well.

What The Developers Say

SocialToo complains that Twitter should let it pay for heavy access to the API if it won’t allow it for free, but Twitter apparently isn’t interested. Third party developers also say that if the API was made more efficient, they could get the information they needed with less wear and tear on Twitter.

These developers who are unhappy with the new policy complain that it will unfairly limit their companies’ growth, that it pulls the rug out from under supporters of the Twitter ecosystem and that it raises the possibility of Twitter reproducing the services they’ve worked hard to develop.

We’re less concerned about unfollowing notifications in particular than we are with the ability for developers to push the limits of accessing this incredible store of data to create unforeseen and otherwise impossible innovations.

What does Twitter have to say about this? We asked them.

What Twitter Says

We pinged Twitter headquarters for a comment and this is what Alex Payne, API Lead at Twitter, had to say.
al3x-1.jpg

We picked the 20,000 requests per hour number precisely because it effects the fewest applications (less than ten of the hosts we see in our hourly report of high-traffic consumers of our site). In most cases, these larger Twitter applications make requests from multiple IPs. Since each of their IPs gets its own 20k/hour allotment of
requests, the developers behind these big Twitter API projects shouldn’t have to lift a finger. 

We’re constantly upgrading our API technologies and educating developers about offerings we already have that they may not know about, including the Search API, Data Mining Feed, and the upcoming “firehose” of all public tweets. We prioritize this work based on what’s going to have the most benefit for the broadest reach of applications.

The fact that 100% Twitter-powered companies like StockTwits are getting funding and expanding in popularity suggests that the Twitter API is meeting the needs of successful, growing businesses today.

 

At first we bought that explanation, but the more we thought about it the more doubt crept into our minds. That statement reads like a PR agent had a heavy hand in writing it.

Is Payne really saying that big companies will be fine, data that the company selectively exposes (tweets vs. profile data) will remain available and it’s only a handful of developers that will be impacted? What if in that handful of developers there are people who are working on building a game changing service that we as users will be really excited about? We love Twitter but our loyalties lie with the developer community that builds on top of its service first.

Maybe we’re wrong, though, and Payne’s response is reasonable. Maybe the handful of developers who want to ping Twitter to death are just loser freaks with too much time on their hands, not enough business development skills and nowhere near the style of Twitter’s new friends in Hollywood and on Madison Avenue! Really, though, maybe Twitter isn’t putting future innovation at risk in order to take the easy way out on scalability challenges. What do you think?

如何开发令用户兴奋的API是每个WEB开发人员心中每时每刻思考的问题,但如何确保成功开发的API即能始终满足不断增长的用户数量,又能符合网站的动态发展以及维持稳定的运作状态,这个问题才是大问题。

这不但体现了开发者的技术能力和网站运营团队的远见,而且直接影响那些贪婪、花心用户的忠诚度,更要命的是关系到互联网食物链下一环的那些为用户提供各类网站API聚合的网站生存。

不过这倒是为那些有兴趣投资的外部资金提供了可乘之机。

一切都很美妙啊,让我们走着瞧吧!