blocks|key|357483|text|我会去看看OpenSocial，这是一个为社交网络sices创建应用编程接口标准的运动。他们使用REST来实现这一点，并采用“以用户为中心”的方法。但这是一种非常有文档记录的方法，即使对一个不完全基于社交的网站也可能有所帮助。如果您正在寻找一些内部代码实现，请查看Drupals、hook+system和Wordpress。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357484|http://code.google.com/apis/opensocial/|offset|length|357485|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|13|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

I would check out OpenSocial, a movement to create an API Standard for social network sices. They use REST for this and have a 'user' centric approach. But this is a very well documented approach which might help for even a site that is not totally Social based. If you are looking for some internal code implementations look at Drupals hook system and Wordpress. 

<a href="http://code.google.com/apis/opensocial/" rel="nofollow noreferrer">http://code.google.com/apis/opensocial/</a>

blocks|key|3142725|text|这将取决于你的目标受众是什么。如果是.net商店，那么soap可能还可以，否则专注于REST，因为它的入门门槛要低得多。从那里看一下针对你想要的相同的人的网站API。这样，您的api就会觉得很熟悉。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3142726|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It will depend on what your target audience is. If it is .net shops then soap is probably okay other wise focus on REST since it has a much lower bar of entry.
From there look at website APIs that target the same people you would like to. This way your api will feel familiar.

blocks|key|3355644|text|我没有任何使用其他API的经验，但即使经过多年的发展，Facebook+API仍然很糟糕。它与“黄金标准”相去甚远。相反，这是人们努力克服并咬紧牙关的事情，因为一旦他们最终做对了，它可以增加很多价值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3355645|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I don't have any experience with the others, but even as it has evolved over the years, the Facebook API is still awful. It doesn't come anywhere near being a "gold standard." Rather, it is something people struggle through and grit their teeth because once they finally get it right, it can add a lot of value.

blocks|key|3355650|text|我们自己也在这方面做了一些研究。在网站API参考的“黄金标准”方面，并没有太多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3355651|引用的最常见的网站API包括：|3355652|http://developers.google.com/api-client-library/java/apis|offset|length|3355653|Amazon+http://docs.amazonwebservices.com/AmazonS3/latest/API/|unordered-list-item|3355654|
|3355655|Twitter+https://dev.twitter.com/|3355656|3355657|Facebook+http://developers.facebook.com/|3355658|3355659|LinkedIn+http://developer.linkedin.com/index.jspa|3355660|3355661|Delicious+http://delicious.com/help/api|3355662|3355663|YouTube+http://www.youtube.com/dev|3355664|3355665|Netflix+http://developer.netflix.com/|3355666|3355667|Sun+http://kenai.com/projects/suncloudapis/pages/Home|3355668|
+|3355669|+S3+Google|3355670|3355671|另一个列表如下：|3355672|http://www.pingable.org/the-top-15-web-apis-for-your-site/|3355673|有人推荐Restful+Web+Services这本书作为这方面的很好的参考。|3355674|(请随时编辑以上列表，添加其他具有API的高知名度网站)|3355675|entityMap|0|LINK|mutability|MUTABLE|url|1|http://docs.amazonwebservices.com/AmazonS3/latest/API/|2|https://dev.twitter.com/|3|http://developers.facebook.com/|4|http://developer.linkedin.com/index.jspa|5|http://delicious.com/help/api|6|http://www.youtube.com/dev|7|http://developer.netflix.com/|8|http://kenai.com/projects/suncloudapis/pages/Home|9|10|https://rads.stackoverflow.com/amzn/click/com/0596529260^0|0|0|0|1L|0|0|7|1I|1|0|0|8|O|2|0|0|9|V|3|0|0|9|14|4|0|0|A|T|5|0|0|8|Q|6|0|0|8|T|7|0|0|4|1D|8|0|0|0|0|0|0|1M|9|0|4|K|A|0|0^^$0|@$1|2|3|4|5|6|7|29|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2A|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|2B|8|@]|9|@$F|2C|G|2D|1|2E]]|A|$]]|$1|H|3|I|5|J|7|2F|8|@]|9|@$F|2G|G|2H|1|2I]]|A|$]]|$1|K|3|L|5|6|7|2J|8|@]|9|@]|A|$]]|$1|M|3|N|5|J|7|2K|8|@]|9|@$F|2L|G|2M|1|2N]]|A|$]]|$1|O|3|L|5|6|7|2O|8|@]|9|@]|A|$]]|$1|P|3|Q|5|J|7|2P|8|@]|9|@$F|2Q|G|2R|1|2S]]|A|$]]|$1|R|3|L|5|6|7|2T|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|2U|8|@]|9|@$F|2V|G|2W|1|2X]]|A|$]]|$1|U|3|L|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|V|3|W|5|J|7|2Z|8|@]|9|@$F|30|G|31|1|32]]|A|$]]|$1|X|3|L|5|6|7|33|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|J|7|34|8|@]|9|@$F|35|G|36|1|37]]|A|$]]|$1|10|3|L|5|6|7|38|8|@]|9|@]|A|$]]|$1|11|3|12|5|J|7|39|8|@]|9|@$F|3A|G|3B|1|3C]]|A|$]]|$1|13|3|L|5|6|7|3D|8|@]|9|@]|A|$]]|$1|14|3|15|5|J|7|3E|8|@]|9|@$F|3F|G|3G|1|3H]]|A|$]]|$1|16|3|17|5|6|7|3I|8|@]|9|@]|A|$]]|$1|18|3|19|5|J|7|3J|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|3K|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|3L|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|3M|8|@]|9|@$F|3N|G|3O|1|3P]]|A|$]]|$1|1F|3|1G|5|6|7|3Q|8|@]|9|@$F|3R|G|3S|1|3T]]|A|$]]|$1|1H|3|1I|5|6|7|3U|8|@]|9|@]|A|$]]|$1|1J|3|-4|5|6|7|3V|8|@]|9|@]|A|$]]]|1K|$1L|$5|1M|1N|1O|A|$1P|E]]|1Q|$5|1M|1N|1O|A|$1P|1R]]|1S|$5|1M|1N|1O|A|$1P|1T]]|1U|$5|1M|1N|1O|A|$1P|1V]]|1W|$5|1M|1N|1O|A|$1P|1X]]|1Y|$5|1M|1N|1O|A|$1P|1Z]]|20|$5|1M|1N|1O|A|$1P|21]]|22|$5|1M|1N|1O|A|$1P|23]]|24|$5|1M|1N|1O|A|$1P|25]]|26|$5|1M|1N|1O|A|$1P|1E]]|27|$5|1M|1N|1O|A|$1P|28]]]]

We're doing some research in this area ourselves. Not a lot out there in terms of "gold standard" for website API references.

The most common website APIs referenced are:

<ul>
<li>Google APIs <a href="http://developers.google.com/api-client-library/java/apis" rel="nofollow noreferrer">http://developers.google.com/api-client-library/java/apis</a></li>
<li>Amazon S3 <a href="http://docs.amazonwebservices.com/AmazonS3/latest/API/" rel="nofollow noreferrer">http://docs.amazonwebservices.com/AmazonS3/latest/API/</a></li>
<li>Twitter <a href="https://dev.twitter.com/" rel="nofollow noreferrer">https://dev.twitter.com/</a></li>
<li>Facebook <a href="http://developers.facebook.com/" rel="nofollow noreferrer">http://developers.facebook.com/</a></li>
<li>LinkedIn <a href="http://developer.linkedin.com/index.jspa" rel="nofollow noreferrer">http://developer.linkedin.com/index.jspa</a></li>
<li>Delicious <a href="http://delicious.com/help/api" rel="nofollow noreferrer">http://delicious.com/help/api</a></li>
<li>YouTube <a href="http://www.youtube.com/dev" rel="nofollow noreferrer">http://www.youtube.com/dev</a></li>
<li>Netflix <a href="http://developer.netflix.com/" rel="nofollow noreferrer">http://developer.netflix.com/</a></li>
<li>Sun Cloud API <a href="http://kenai.com/projects/suncloudapis/pages/Home" rel="nofollow noreferrer">http://kenai.com/projects/suncloudapis/pages/Home</a></li>
</ul>

Another list here:

<a href="http://www.pingable.org/the-top-15-web-apis-for-your-site/" rel="nofollow noreferrer">http://www.pingable.org/the-top-15-web-apis-for-your-site/</a>

Someone recommended the book <a href="https://rads.stackoverflow.com/amzn/click/com/0596529260" rel="nofollow noreferrer" rel="nofollow noreferrer">Restful Web Services</a> as a good reference on this.

(please feel free to edit the above list to add other high profile websites with APIs)

blocks|key|356835|text|Last.fm的api仍然是网络上维护最好的api之一。它存在的时间也比大多数都要长，因为它基本上就是这样开始的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356836|http://www.last.fm/api|offset|length|356837|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|M|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

Last.fm's api continues to be one of the most well maintained apis on the net. It's also been around longer than most, because it started out basically as just that. 

<a href="http://www.last.fm/api" rel="nofollow noreferrer">http://www.last.fm/api</a>

blocks|key|3142857|text|一些非常好的API：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3142858|3142859|Last.FM+http://www.last.fm/api+(wonderful+|unordered-list-item|offset|length|3142860|Last.FMhttp://www.last.fm/api(wonderful|3142861|Last.FMhttp://www.last.fm/api(愉快合作，深思熟虑))|3142862|)|3142863|entityMap|0|LINK|mutability|MUTABLE|url|http://www.last.fm/api|1|2^0|0|0|8|M|0|0|7|M|1|0|7|M|2|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Z|8|@]|9|@$F|10|G|11|1|12]]|A|$]]|$1|H|3|I|5|E|7|13|8|@]|9|@$F|14|G|15|1|16]]|A|$]]|$1|J|3|K|5|E|7|17|8|@]|9|@$F|18|G|19|1|1A]]|A|$]]|$1|L|3|M|5|6|7|1B|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|U]]|W|$5|Q|R|S|A|$T|U]]]]

Some APIs which are notably good:

<ul>
<li>Last.FM <a href="http://www.last.fm/api" rel="nofollow noreferrer">http://www.last.fm/api</a> (wonderful documentation)</li>
<li>Github <a href="http://develop.github.com/" rel="nofollow noreferrer">http://develop.github.com/</a> (pleasure to work with, well thought out)</li>
</ul>

blocks|key|3355736|text|Joshua+Bloch的一篇60分钟的谷歌技术演讲How+To+Design+A+Good+API+and+Why+it+Matters很有意义。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3355737|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Joshua_Bloch|1|http://www.youtube.com/watch?v=aAb7hSCtvGw^0|0|C|0|Q|17|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

<a href="http://www.youtube.com/watch?v=aAb7hSCtvGw" rel="noreferrer">How To Design A Good API and Why it Matters</a>, a 60 minute Google tech talk by <a href="http://en.wikipedia.org/wiki/Joshua_Bloch" rel="noreferrer">Joshua Bloch</a>, is relevant.

blocks|key|3355761|text|关于杰夫的大API列表:我非常确定不是的意思是“黄金标准”。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3355762|不需要保存广泛使用的API的手动列表。要获取列表，请查看http://www.programmableweb.com/apis/directory/1?sort=mashups。|3355763|因为我喜欢将REST作为松散的标准，所以当API有意义且直观时，我会说它是“黄金”。|3355764|3355765|推特(+http://apiwiki.twitter.com/+)、|unordered-list-item|3355766|Github+(+http://develop.github.com/+)和|3355767|Last.FM(+http://www.last.fm/api+)+|3355768|3355769|…所有这些对我来说都是最有意义的，而且都经过了深思熟虑(正如Brian已经指出的那样)。|3355770|在我目前的日常工作中，我也经常使用OpenSocial，其中URI感觉非常自然，但也以自己的方式扩展了REST标准。|3355771|如果你喜欢它的严格和安全，使用SOAP。|3355772|entityMap|0|LINK|mutability|MUTABLE|url|http://www.programmableweb.com/apis/directory/1?sort=mashups|1|http://apiwiki.twitter.com/|2|http://develop.github.com/|3|http://www.last.fm/api^0|H|2|0|S|1O|0|0|0|0|4|R|1|0|9|Q|2|0|9|M|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1F|8|@]|D|@$9|1G|A|1H|1|1I]]|E|$]]|$1|H|3|I|5|6|7|1J|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|1L|8|@]|D|@$9|1M|A|1N|1|1O]]|E|$]]|$1|N|3|O|5|M|7|1P|8|@]|D|@$9|1Q|A|1R|1|1S]]|E|$]]|$1|P|3|Q|5|M|7|1T|8|@]|D|@$9|1U|A|1V|1|1W]]|E|$]]|$1|R|3|-4|5|6|7|1X|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1Y|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|20|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|21|8|@]|D|@]|E|$]]]|Z|$10|$5|11|12|13|E|$14|15]]|16|$5|11|12|13|E|$14|17]]|18|$5|11|12|13|E|$14|19]]|1A|$5|11|12|13|E|$14|1B]]]]

Regarding Jeff's list of big APIs: I am pretty sure that common does not mean "Gold Standard".

No need to keep a manual list of widespread API. To get a list check out <a href="http://www.programmableweb.com/apis/directory/1?sort=mashups" rel="nofollow noreferrer">http://www.programmableweb.com/apis/directory/1?sort=mashups</a> .

Since I like REST as loose standard, I'd say that an API is "Golden" when it makes sense and is intuitive. 

<ul>
<li>Twitter ( <a href="http://apiwiki.twitter.com/" rel="nofollow noreferrer">http://apiwiki.twitter.com/</a> ),</li>
<li>Github ( <a href="http://develop.github.com/" rel="nofollow noreferrer">http://develop.github.com/</a> ) and</li>
<li>Last.FM ( <a href="http://www.last.fm/api" rel="nofollow noreferrer">http://www.last.fm/api</a> ) </li>
</ul>

… all make the most sense for me and are well thought out (as Brian already pointed out).

In my current daily work I also work a lot with OpenSocial, where URIs feel very natural but also extend the REST standard in its own way.

If you like it strict and safe, use SOAP.

blocks|key|3142964|text|在我看来，应用编程接口的文档与应用编程接口的实际设计一样重要(或者更重要)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3142965|写得好的、简单的文档将弥补任何设计缺陷。这就是我在看了已经发布的各种链接后了解到的。具体来说，Last.fm的文档看起来非常好:易于导航和易于理解。|3142966|entityMap^0|5|9|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

It would seem to me that the documentation of the API is just as (or more) important than the actual design of the API. 

Well written, simple documentation will make up for any design flaws. That's what I've learned after looking at the various links posted already. Specifically, Last.fm's documentation seems very good: easy to navigate and easy to understand.

blocks|key|3355817|text|Force+(原名SalesForce)接口：http://www.salesforce.com/us/developer/docs/api/index.htm|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3355818|entityMap|0|LINK|mutability|MUTABLE|url|http://www.salesforce.com/us/developer/docs/api/index.htm^0|N|1L|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Force (previously known as SalesForce) API: <a href="http://www.salesforce.com/us/developer/docs/api/index.htm" rel="nofollow noreferrer">http://www.salesforce.com/us/developer/docs/api/index.htm</a>

blocks|key|356909|text|我认为最好的答案是列出好的web的characteristics，而不是举例子。如果你喜欢Twitter/Facebook/等API，你觉得这些API的哪些方面有吸引力？|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|356910|我要先试一试：|356911|356912|记录良好的API，包括约束和使用策略。这样就可以自信地快速开发，而不是再次猜测参数可能意味着什么，以及are.|ordered-list-item|356913|Technology/language不可知API的返回值是什么。好的API应该易于使用，跨多种语言和平台提供相同的功能。|356914|支持良好的API。总会有bug的。响应式维护者带来了更多可用的API+|356915|分层API集。当API被整齐地分层时，广泛的开发人员可以使用他们需要的部分，而不需要引入无关的层。另外，它迫使创建者努力考虑干净和组件化的API。|356916|356917|请在评论中添加更多。|356918|entityMap^0|H|F|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|10|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|11|8|@]|D|@]|E|$]]|$1|L|3|M|5|K|7|12|8|@]|D|@]|E|$]]|$1|N|3|O|5|K|7|13|8|@]|D|@]|E|$]]|$1|P|3|Q|5|K|7|14|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|15|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|16|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|V|$]]

I think the best way to answer is to list the characteristics of good web APIs instead of citing examples. If you like Twitter/Facebook/etc APIs, what aspect of these APIs do you find attractive?

I'll take a first stab:

<ol>
<li>Well documented APIs, including constraints and usage policies. This enables rapid development with confidence, instead of second guessing what the parameters might mean, and what return values are.</li>
<li>Technology/language agnostic APIs. Good APIs should be easily usable, providing the same functionality, across a wide array of languages and platforms. </li>
<li>Well supported APIs. There are always bugs. Responsive maintainers result in more usable APIs</li>
<li>Layered API sets. When APIs are neatly layered, a wide range of developers can consume the pieces they need without needing to pull in extraneous layers. As a plus, it forces the creators to think hard about clean and componentized APIs.</li>
</ol>

Please add more to comments.

blocks|key|3355930|text|在与几个人一起工作过之后，我将直接进入正题|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3355931|3355932|Facebook|unordered-list-item|3355933|3355934|-+GOOD:+clean+and+relatively+consistent.++Performs+well+and+most+things+logically+make+sense.++FQL+is+pretty+neat.++XML+and+JSON+options.++No+pre-conception+of+response+format+other+than+what+you+really+need
-+BAD:+Changes+often+and+without+warning.++'official'+api+libraries+are+pretty+atrocious.+documentation+of+many+calls+are+poor+or+missing.++Non-standard+authentication+(some+may+call+this+good?)|code-block|syntax|javascript|3355935|​|3355936|3355937|Myspace|3355938|3355939|-+GOOD:+open+standards+(oAuth+authentication,+Opensocial+endpoint)
-+BAD:+often+broken.++Usage+of+oauth+is+very+nonstandard+and+breaks+most+client+libraries.+official+client+libraries+are+terrible.|3355940|3355941|3355942|Photobucket+(免责声明:我编写了photobucket+api的服务器端)|3355943|3355944|-+GOOD:+open+standard+authentication+(oauth).++xml,+json,+even+php+serialized+array+format+as+response+parameters.++faithful+REST+(get/put/delete/post+on+'noun'+urls).
-+BAD:+not+many+client+libraries.++Architectural+challenges+with+standard+oauth+libraries+(users+live+on+subdomains,+calls+must+be+made+to+subdomain,+so+url+has+to+change).|3355945|3355946|3355947|Twitter|3355948|3355949|-+GOOD:+pretty+consistent+(though+api+vs+search+api+has+diffs).++Good+REST+practice.++OAuth+authentication+as+well+as+supporting+oldschool+Basic.++
-+BAD:+error+rate+(pretty+much+consistent+with+rest+of+twitter+though).++Odd+format+of+some+return+values+(like+their+date+format).|3355950|3355951|理想特性|offset|length|style|BOLD|3355952|3355953|我不喜欢“严格”的REST。在某些客户端语言中，PUT和DELETE会导致问题。GET和POST使用适当的“动词”似乎就足够了。此外，类似RPC的函数名称可以接受，只要它们是逻辑的，甚至是URI的一部分。在这种情况下，object+In仍然需要非常一致的though.|3355954|Standard身份验证/授权。Basic/Digest也可以，但我是OpenID/oAuth的粉丝(如果你想获得优势，也可以使用WRAP+)。使用自己的代码意味着你必须100%25地解释它，并且有可能为everyone.|3355955|Standard数据类型编写客户端库。确保您的数据类型(+'true‘或1，而不是某种混合)是一致的，并支持最通用的标准。Datetime应为ISO8601。地理位置应该看起来像GeoRSS，等等。你应该能够为你的返回类型创建一个XSD/GeoRSS/任何严格的验证器。期望您的inputs.|3355956|Simple返回结构具有相同的标准。XML-RPC/+JSON+-RPC有一些好处，因为你知道你得到的是什么，但是在任何情况下，如果我不能很容易地用JSON或PHP的SimpleXML解析你的返回类型，并且本质上把它序列化为一致的散列，我会生气的。|3355957|支持无中断的扩展/扩展。不要把自己编码到角落里，让它很难添加到你的API中。试着提前做出正确的决定，你不会改变constantly.|3355958|Documentation！确保它是好的，并解释所有的事情。即使到那时，它也不够好，所以请确保你有专门的时间来处理它，并有一个支持论坛或其他任何东西来保持它的更新。|3355959|3355960|所以这么说...介于Facebook和Twitter之间的东西。当然，我偏爱我们在Photobucket上的一些东西，但我也讨厌其中的一些。|3355961|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|4|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1Y|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|20|8|@]|9|@]|A|$J|K]]|$1|L|3|M|5|6|7|21|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|O|3|P|5|E|7|23|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|R|3|S|5|I|7|25|8|@]|9|@]|A|$J|K]]|$1|T|3|M|5|6|7|26|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|27|8|@]|9|@]|A|$]]|$1|V|3|W|5|E|7|28|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|29|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|I|7|2A|8|@]|9|@]|A|$J|K]]|$1|10|3|M|5|6|7|2B|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|12|3|13|5|E|7|2D|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|15|3|16|5|I|7|2F|8|@]|9|@]|A|$J|K]]|$1|17|3|M|5|6|7|2G|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2H|8|@$1A|2I|1B|2J|1C|1D]]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2K|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|E|7|2L|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|E|7|2M|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|E|7|2N|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|E|7|2O|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|E|7|2P|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|E|7|2Q|8|@]|9|@]|A|$]]|$1|1R|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]|$1|1S|3|1T|5|6|7|2S|8|@]|9|@]|A|$]]|$1|1U|3|-4|5|6|7|2T|8|@]|9|@]|A|$]]]|1V|$]]

Having worked with a few, I'll get right down to it

<ul>
<li>Facebook

<ul>
<li>GOOD: clean and relatively consistent. Performs well and most things logically make sense. FQL is pretty neat. XML and JSON options. No pre-conception of response format other than what you really need</li>
<li>BAD: Changes often and without warning. 'official' api libraries are pretty atrocious. documentation of many calls are poor or missing. Non-standard authentication (some may call this good?)</li>
</ul></li>
<li>Myspace

<ul>
<li>GOOD: open standards (oAuth authentication, Opensocial endpoint)</li>
<li>BAD: often broken. Usage of oauth is very nonstandard and breaks most client libraries. official client libraries are terrible.</li>
</ul></li>
<li>Photobucket (disclaimer: I wrote the server side of the photobucket api)

<ul>
<li>GOOD: open standard authentication (oauth). xml, json, even php serialized array format as response parameters. faithful REST (get/put/delete/post on 'noun' urls).</li>
<li>BAD: not many client libraries. Architectural challenges with standard oauth libraries (users live on subdomains, calls must be made to subdomain, so url has to change).</li>
</ul></li>
<li>Twitter

<ul>
<li>GOOD: pretty consistent (though api vs search api has diffs). Good REST practice. OAuth authentication as well as supporting oldschool Basic. </li>
<li>BAD: error rate (pretty much consistent with rest of twitter though). Odd format of some return values (like their date format).</li>
</ul></li>
</ul>

Ideal characteristics

<ul>
<li>I'm not sold on 'strict' REST. PUT and DELETE cause problems in some client languages. GET and POST seem to be sufficient with appropriate 'verbs'. Also, RPC-like function names are OK with me as long as they're logical and maybe even part of the URI. In that case, object IDS still need to be very consistent though.</li>
<li>Standard authentication/authorization. Basic/Digest can be ok, but I'm a fan of OpenID/oAuth (or WRAP if you want to get bleeding edge). Rolling your own means you have to explain 100% of it, and potentially write client libraries for everyone.</li>
<li>Standard datatypes. Make sure you are consistent about your datatypes (either 'true' or 1, not some mix), and support the most generic standards. Datetime should be ISO8601. Geolocation should 'look like' GeoRSS, etc. You should be able to create an XSD/relaxNG/whatever strict validator for your return types. Expect the same standards from your inputs.</li>
<li>Simple return structure. there's some benefit to XML-RPC/JSON-RPC in that you kinda know what you're getting back, but in any case, if I cant easily parse your return type with JSON or something like PHP's SimpleXML and essentially serialize it to a consistent hash, I'm going to be pissed. </li>
<li>Support extension/expansion without breakage. Dont code yourself into a corner and make it hard to add to your API. Try to make good decisions up front that you wont be changing constantly.</li>
<li>Documentation! Make sure its good, and explains everything. Even then it won't be good enough, so make sure you have dedicated time to work on it and a supporting forum or whatever to keep it up to date. </li>
</ul>

So that being said... something between Facebook and Twitter. Of course I'm partial to some of the stuff we have on Photobucket, but I also hate some of it.

blocks|key|357634|text|AtomPub是黄金标准，因为它是由互联网上一些最聪明的人设计的。使用iit作为基础，你不能走得太远。这就是谷歌和微软所做的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357635|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

AtomPub is the gold standard because it was designed by some of the brightest minds on the internet. You can't go too far wrong using iit as a basis. That is what google and msft does.

blocks|key|3143139|text|有一个类似的问题，没有得到太多的行动，但认为这将是一个很好的链接。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3143140|What+web+APIs+would+you+most+want+to+replicate+or+are+the+most+popular?|offset|length|3143141|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/775988/what-web-apis-would-you-most-want-to-replicate-or-are-the-most-popular^0|0|0|1Z|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Had a similar question to this which didn't get much action, but thought it would be good to link to it.

<a href="https://stackoverflow.com/questions/775988/what-web-apis-would-you-most-want-to-replicate-or-are-the-most-popular">What web APIs would you most want to replicate or are the most popular?</a>

blocks|key|360417|text|如果我现在正在为一个现有的网站设计一个web，假设这个网站在正确使用HTTP方面做了很好的设计，我会使用现有的网站作为设计指南。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360418|以Stack+Overflow为例，它已经将的整个URI空间映射为。它在不同的表示之间定义了一套完整的互连。站点的用户已经熟悉了站点结构，因此应该已经很熟悉了。|offset|length|style|BOLD|360419|惟一需要更改的部分是表示的内容，以消除所有不必要的标记。有必要添加一些额外的模板化链接，以允许当前只能通过javascript访问的搜索。例如，通过导航搜索用户并不容易，因为目前链接是通过javascript构建的。|360420|真正棘手的决定是使用什么媒体类型的。您可以使用带有RDFa样式元数据标记的基本html，也可以在Html5中使用新的微数据格式。或者，您可以返回基于xml或Json的自定义媒体类型。自定义媒体类型使得版本控制变得非常容易，但对于那些不能直接访问StackOverflow的客户端来说，它的可访问性较低。自定义类型可以与Atom+feed结合使用，Atom+feed大多已经存在于StackOverflow中，|360421|设计web实际上与设计网站没有什么不同，只是您交付的内容将由非web浏览器的程序使用。|360422|你不想做的是创建一个基于的数据访问层。这就像向世界展示你的内裤一样。现有的网站针对所有常见的使用场景进行了优化，许多api访问模式都将是相似的，因此可以重用已经创建的“视图”。可能有必要在这里和那里添加一些额外的链接，以使程序更快地获得他们想要的数据，但这些链接可以随着需要的增加而增加。|360423|编写良好的网站对于web浏览器客户端来说已经是非常有效的API，真的没有必要重新开始支持任何其他类型的客户端。API结构不需要更改，只需要更改交付的内容即可。|360424|entityMap^0|0|M|B|1L|B|0|0|C|0|5|C|0|0|D|0|C|6|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|18|8|@$D|19|E|1A|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1B|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|S|$]]

If I were designing a web api today for an existing web site, assuming the web site was well designed with respect to its proper usage of HTTP, I would use the existing web site as the design guideline. 

Take Stack Overflow as an example, it has the entire URI space already mapped out. It has a complete set of interconnections defined between the different representations. Users of the site are already familiar with the site structure and therefore the API structure would already be familiar. 

The only part that needs to change is the content of the representations, to eliminate all unnecessary markup. It would be necessary to add in a few extra templated links to allow for searches that are currently only accessible via javascript. For example, searching for a user is not easily discoverable via navigating because currently the link is built via javascript.

The really tricky decision is what media-type to use. You could use bare bones html with RDFa style metadata markup, or go wild and use the new Microdata format in Html5. Or, you could return a custom media type based on xml or Json. Something like application/vnd.stackoverflow.question+xml, etc. The custom media type makes versioning really easy, but it is less accessible to clients that were not designed to access StackOverflow directly. The custom types could be used in combination with Atom feeds which are mostly already there in StackOverflow,

Designing a web api is really no different than designing a website, other than the fact that you are delivering content that will be consumed by a program that is not a web browser.

What you don't want to do is create an Http based data access layer. That is just like showing your underwear to the world. The existing web site is optimized for all the common usage scenarios, many of the api access patterns are going to be similar, so reuse the "views" that have already been created. It may be necessary to add a few extra links here and there to make it a bit quicker for programs to get the data they want, but those can be added incrementally as the need arises.

Well written web sites are already very effective APIs for web browser clients, it is really not necessary to go back to the drawing board to support any other type of client. The API structure does not need to change, just the delivered content.

Seems like there are two categories of APIs for websites today. 

<ol>
<li>APIs which allow the functionality of the site to be extended like Facebook, Myspace, etc. These APIs seem to be very diverse.</li>
<li>APIs which allow interaction with the existing site functionality like Twitter, Flickr, etc. These all claim to be REST based, but are in reality simply "data over HTTP".</li>
</ol>

If you were creating a website that allowed both functional extension and outside interaction, what existing APIs would you use as a reference model?

What is the gold standard for website APIs?  Twitter, Flickr, Facebook, etc

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

现在的网站似乎有两类API。允许扩展站点功能的API，如Facebook、Myspace等。这些API似乎非常多样化。API允许与现有站点功能交互，如Twitter、Flickr等。这些API都声称是基于REST的，但实际上只是“通过HTTP传输数据”。如果你正在创建一个同时允许功能扩展和外部交互的网站，你会使用哪些现...

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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