61

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

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

  2. Twitter、Flickr などの既存のサイト機能との対話を可能にする API。これらはすべて REST ベースであると主張していますが、実際には単に「HTTP 経由のデータ」です。

機能の拡張と外部とのやり取りの両方を可能にする Web サイトを作成する場合、参照モデルとしてどの既存の API を使用しますか?

4

15 に答える 15

37

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

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

ここに別のリストがあります：

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

これに関する良い参考書として、ある人がRestful Web Servicesという本を勧めました。

(上記のリストを自由に編集して、API を備えた他の知名度の高い Web サイトを追加してください)

于 2010-02-05T06:31:58.863 に答える
16

数人で作業したので、すぐに理解します

  • フェイスブック

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

  • 私のスペース

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

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

    • 良い例：オープンスタンダード認証（oauth）。xml、json、さらにはphpシリアル化された配列形式を応答パラメーターとして使用します。忠実なREST（「名詞」URLのget / put / delete / post）。
    • 悪い例：クライアントライブラリはあまりありません。標準の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である必要があります。ジオロケーションは「GeoRSSなど」のように見えるはずです。XSD/relaxNG/リターンタイプ用の厳密なバリデーターを作成できるはずです。入力から同じ基準を期待してください。
  • シンプルなリターン構造。XML-RPC / JSON-RPCには、何が返されるかがある程度わかっているという利点がありますが、いずれにせよ、JSONまたはPHPのSimpleXMLのようなものを使用して戻り型を簡単に解析できず、基本的に一貫性のあるものにシリアル化できない場合ハッシュ、私は腹を立てるつもりです。
  • 破損することなく拡張/拡張をサポートします。自分を隅々までコーディングして、APIに追加しにくくしないでください。絶えず変化することのないように、前もって適切な決定を下すようにしてください。
  • ドキュメンテーション！それが良いことを確認し、すべてを説明します。それでも十分ではないので、それに取り組むための専用の時間と、それを最新の状態に保つためのサポートフォーラムまたは何かを持っていることを確認してください。

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

于 2010-02-05T15:48:59.337 に答える
11

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

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

于 2010-02-05T08:42:13.447 に答える
8

Last.fm の API は、ネット上で最もよく管理されている API の 1 つであり続けています。また、基本的にはそれだけで始まったので、ほとんどの場合よりも長く使用されています.

http://www.last.fm/api

于 2010-02-05T06:41:32.943 に答える
4

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

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

于 2008-11-17T21:32:44.393 に答える
3

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

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

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

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

于 2010-02-05T10:30:00.290 に答える
2

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

于 2010-02-05T06:43:59.510 に答える
2

私は他の API を使った経験はありませんが、Facebook API は何年にもわたって進化してきましたが、いまだにひどいものです。それは「ゴールド スタンダード」にはほど遠いものです。むしろ、それは人々が苦労して歯を食いしばることです。

于 2009-12-28T18:25:17.457 に答える
1

それはあなたのターゲットオーディエンスが何であるかによって異なります。それが .net ショップである場合、SOAP はおそらく問題ありません。それ以外の場合は REST に焦点を当てます。参入障壁がはるかに低いためです。そこから、あなたが望んでいるのと同じ人々を対象とする Web サイト API を見てください。このようにして、API は親しみやすくなります。

于 2008-11-17T21:57:40.007 に答える
0

AtomPub は、インターネット上で最も優れた頭脳によって設計されているため、ゴールド スタンダードです。iit を基礎として使用することで、間違った方向に進むことはありません。それが、Google と msft が行うことです。

于 2010-02-05T17:08:24.400 に答える
0

これと同様の質問がありましたが、あまりアクションがありませんでしたが、リンクするとよいと思いました。

最もレプリケートしたい、または最も人気のある Web API はどれですか?

于 2010-02-06T01:57:42.043 に答える
0

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

スタック オーバーフローを例にとると、URI 空間全体が既にマップされています。これには、異なる表現間で定義された相互接続の完全なセットがあります。サイトのユーザーは既にサイトの構造に精通しているため、API の構造にも既に精通しているはずです。

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

本当にトリッキーな決定は、使用する media-typeです。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 構造を変更する必要はなく、提供されるコンテンツだけを変更する必要があります。

于 2010-02-08T04:06:01.647 に答える
0

Force (以前の SalesForce) API: http://www.salesforce.com/us/developer/docs/api/index.htm

于 2010-02-05T09:39:30.070 に答える