web-dev-qa-db-ja.com

ウェブサイトAPIのゴールドスタンダードは何ですか？ Twitter、Flickr、Facebookなど

今日のWebサイトには2つのカテゴリのAPIがあるようです。

  1. FacebookやMyspaceなどのようにサイトの機能を拡張できるようにするAPI。これらのAPIは非常に多様であるように思われます。

  2. Twitter、Flickrなどの既存のサイト機能との相互作用を可能にするAPI。これらはすべてRESTベースであると主張していますが、実際には単に「dataoverHTTP」です。

機能拡張と外部インタラクションの両方を許可するWebサイトを作成する場合、参照モデルとしてどの既存のAPIを使用しますか？

restapi-designasp.net-web-api
61
Jason

私たちはこの分野で自分たちでいくつかの研究を行っています。 WebサイトAPIリファレンスの「ゴールドスタンダード」に関してはそれほど多くはありません。

参照される最も一般的なWebサイトAPIは次のとおりです。

ここに別のリスト：

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

誰かがこの本を推薦しました Restful Web Services これに関する良い参考資料として。

（上記のリストを自由に編集して、APIを備えた他の有名なWebサイトを追加してください）

37
Jeff Atwood

優れたAPIを設計する方法とその重要性 、 Joshua Bloch による60分間のGoogle技術トークが関連しています。

23
gerry3

いくつかの作業を終えたので、すぐに説明します

  • フェイスブック

    • 良い：クリーンで比較的一貫性があります。うまく機能し、ほとんどのものは論理的に理にかなっています。 FQLはかなりきちんとしています。 XMLおよびJSONオプション。本当に必要なもの以外の応答形式の先入観はありません
    • 悪い例：頻繁に警告なしに変更されます。 「公式」APIライブラリはかなりひどいものです。多くの通話のドキュメントが不十分であるか、欠落しています。非標準の認証（これを良いと呼ぶ人もいますか？）

  • 私のスペース

    • 良い例：オープンスタンダード（oAuth認証、Opensocialエンドポイント）
    • 悪い：しばしば壊れています。 oauthの使用は非常に非標準であり、ほとんどのクライアントライブラリを破壊します。公式のクライアントライブラリはひどいものです。

  • Photobucket（免責事項：Photobucket APIのサーバー側を作成しました）

    • 良い例：オープンスタンダード認証（oauth）。 xml、json、さらにはphpシリアル化された配列形式を応答パラメーターとして。忠実なREST（ '名詞'のURLを取得/配置/削除/投稿）。
    • 悪い例：クライアントライブラリが少ない。標準のoauthライブラリでのアーキテクチャ上の課題（ユーザーはサブドメインに住んでいるため、サブドメインを呼び出す必要があるため、URLを変更する必要があります）。

  • ツイッター

    • 良い：かなり一貫性があります（ただし、APIと検索APIには違いがあります）。良いREST練習。OAuth認証、およびoldschoolBasicのサポート。
    • 悪い例：エラー率（Twitterの他の部分とほぼ一致しています）。一部の戻り値の奇数形式（日付形式など）。

理想的な特性

  • 私は「厳格な」RESTでは販売されていません。 PUTとDELETEは、一部のクライアント言語で問題を引き起こします。 GETとPOSTは、適切な「動詞」で十分なようです。また、RPCのような関数名は、論理的であり、URIの一部である限り、問題ありません。ただし、オブジェクトIDSは依然として非常に一貫している必要があります。
  • 標準の認証/承認。 Basic/Digestは問題ないかもしれませんが、私はOpenID/oAuth（または、最先端を取得したい場合はWRAP）のファンです。自分でローリングするということは、その100％を説明し、すべての人のためにクライアントライブラリを作成する必要があることを意味します。
  • 標準のデータ型。データ型（「true」または1のいずれか、一部の組み合わせではない）について一貫性があり、最も一般的な標準をサポートしていることを確認してください。日時はISO8601である必要があります。 Geolocationは 'GeoRSSなどのように見えるはずです。あなたはあなたのリターンタイプのためにXSD/RelaxNG /どんな厳密なバリデーターも作成できるはずです。入力から同じ基準を期待してください。
  • シンプルなリターン構造。 XML-RPC/JSON-RPCには、何が返されるかがある程度わかっているという利点がありますが、いずれにせよ、戻り値の型をJSONまたはPHPのSimpleXMLのようなもので簡単に解析できず、基本的に一貫性のあるものにシリアル化できない場合ハッシュ、私は腹を立てるつもりです。
  • 破損することなく拡張/拡張をサポートします。自分を隅にコーディングして、APIに追加しにくくしないでください。絶えず変化しないように、前もって適切な決定を下してください。
  • ドキュメンテーション！それが良いことを確認し、すべてを説明します。それでも十分ではないので、それに取り組むための専用の時間とサポートフォーラム、またはそれを最新の状態に保つための何かを持っていることを確認してください。

そうは言っても... FacebookとTwitterの間の何か。もちろん、私はPhotobucketにあるもののいくつかに部分的ですが、それのいくつかも嫌いです。

16
Justin

APIのドキュメントは、APIの実際の設計と同じくらい（またはそれ以上）重要であるように思われます。

よく書かれた簡単なドキュメントは、設計上の欠陥を補います。すでに投稿されているさまざまなリンクを見て、それが私が学んだことです。具体的には、Last.fmのドキュメントは非常に優れているようです。ナビゲートしやすく、理解しやすいです。

11
Frank Krueger

ジェフの大きなAPIのリストについて： common はnotはを意味しないと確信しています]「ゴールドスタンダード」。

広く普及しているAPIの手動リストを保持する必要はありません。リストを取得するには、チェックアウトしてください http://www.programmableweb.com/apis/directory/1?sort=mashups 。

私はRESTが緩い標準として好きなので、APIが意味があるであり、直感的。

…すべてが私にとって最も理にかなっており、よく考えられています（ブライアンがすでに指摘したように）。

私の現在の日常業務では、URIが非常に自然に感じられるだけでなく、REST標準を独自の方法で拡張するOpenSocialでも多くの作業を行っています。

厳密で安全な場合は、SOAPを使用してください。

8
digitarald

Last.fmのAPIは、引き続きネット上で最もよく維持されているAPIの1つです。それは基本的にそれと同じように始まったので、それはまたほとんどより長くありました。

http://www.last.fm/api

8
icco

ソーシャルネットワークサイスのAPI標準を作成する運動であるOpenSocialをチェックします。彼らはこれにRESTを使用し、「ユーザー」中心のアプローチを採用しています。しかし、これは非常によく文書化されたアプローチであり、完全にソーシャルベースではないサイトでも役立つ可能性があります。一部の内部コード実装は、DrupalsフックシステムとWordpressを調べます。

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

4
danielrsmith

答える最良の方法は、例を引用するのではなく、優れたWeb APIの特性をリストすることだと思います。 Twitter/Facebook/etc APIが好きなら、これらのAPIのどの側面が魅力的だと思いますか？

私は最初の刺し傷を取ります：

  1. 制約や使用ポリシーなど、十分に文書化されたAPI。これにより、パラメータの意味や戻り値を推測する代わりに、自信を持って迅速に開発できます。
  2. テクノロジー/言語に依存しないAPI。優れたAPIは、さまざまな言語やプラットフォームで同じ機能を提供し、簡単に使用できる必要があります。
  3. 十分にサポートされているAPI。常にバグがあります。レスポンシブメンテナは、より使いやすいAPIをもたらします
  4. 階層化されたAPIセット。 APIがきちんと階層化されていると、幅広い開発者が、無関係な層を引き込むことなく、必要な部分を消費できます。さらに、作成者はクリーンでコンポーネント化されたAPIについて真剣に考える必要があります。

コメントにさらに追加してください。

3
psychotik

特に優れているいくつかのAPI：

2
Brian Gianforcaro

私は他の人との経験はありませんが、それが何年にもわたって進化してきたとしても、FacebookAPIはまだひどいです。それは「ゴールドスタンダード」に近いところはありません。むしろ、それは人々が苦労して歯を食いしばる何かです。なぜなら、彼らが最終的にそれを正しく理解すると、それは多くの価値を追加することができるからです。

2
JoshJordan

それはあなたのターゲットオーディエンスが何であるかに依存します。 .netショップの場合、石鹸はおそらく大丈夫です。それ以外の場合は、エントリのバーがはるかに低いため、REST）に焦点を当てます。 。このようにして、APIはなじみのあるものになります。

1
Aaron Fischer

Force（以前はSalesForceとして知られていました）API： http://www.salesforce.com/us/developer/docs/api/index.htm

0
user266929

これと同様の質問があり、あまり行動を起こさなかったが、それにリンクするのが良いと思った。

どのWeb APIを最も複製したいですか、それとも最も人気がありますか？

0
Greg Roberts

AtomPubは、インターネット上で最も優秀な人々によって設計されたため、ゴールドスタンダードです。 iitをベースとして使用すると、間違いを犯すことはできません。それはグーグルとmsftがすることです。

0
JarrettV

今日、既存のWebサイト用にWeb APIを設計している場合、そのWebサイトがHTTPの適切な使用法に関して適切に設計されていると仮定すると、既存のWebサイトを設計ガイドラインとして使用します。

例としてStackOverflowを取り上げます。これには、RIスペース全体がすでにマップされていますがあります。異なる表現間で定義された相互接続の完全なセットがあります。 サイトのユーザーはすでにサイト構造に精通していますしたがって、API構造はすでに精通しているでしょう。

変更する必要があるのは表現の内容だけです、不要なマークアップをすべて削除します。現在javascript経由でのみアクセス可能な検索を可能にするために、いくつかのテンプレートリンクを追加する必要があります。たとえば、現在リンクはjavascriptを介して構築されているため、ユーザーの検索はナビゲートでは簡単に見つけることができません。

本当にトリッキーな決定はどのメディアタイプを使用するかです。 RDFaスタイルのメタデータマークアップでベアボーンhtmlを使用するか、ワイルドになってHtml5の新しいMicrodata形式を使用することができます。または、xmlまたはJsonに基づいてカスタムメディアタイプを返すこともできます。 application/vnd.stackoverflow.question + xmlなどのようなもの。カスタムメディアタイプを使用すると、バージョン管理が非常に簡単になりますが、StackOverflowに直接アクセスするように設計されていないクライアントはアクセスしにくくなります。カスタムタイプは、ほとんどがStackOverflowにすでに存在するAtomフィードと組み合わせて使用​​できます。

Web APIの設計は、実際にはWebサイトの設計と同じです、Webブラウザーではないプログラムによって消費されるコンテンツを配信しているという事実を除いて。

やりたくないのは、Httpベースのデータアクセス層を作成することです。それはあなたの下着を世界に見せているようなものです。既存のWebサイトは、すべての一般的な使用シナリオに合わせて最適化されており、APIアクセスパターンの多くは類似しているため、すでに作成されている「ビュー」を再利用します。プログラムが必要なデータを取得するのを少し速くするために、あちこちにいくつかの追加リンクを追加する必要があるかもしれませんが、必要に応じてそれらを段階的に追加することができます。

よく書かれたWebサイトはすでにWebブラウザクライアントにとって非常に効果的なAPIであり、他のタイプのクライアントをサポートするために設計図に戻る必要はありません。 API構造を変更する必要はなく、配信されたコンテンツのみを変更する必要があります。

0
Darrel Miller