48

私の会社では、データにアクセスして更新するために Web API に分岐し始めています。最初はパートナー向けですが、将来的には一般公開される可能性があります。現時点では、API の外観 (SOAP、REST、RPC など) は完全にオープンであり、まだ何も決定していません。そのため、人々が優れていると考える Web API の例と、あなたがそう考える理由の両方に興味があります。それ。

私が興味を持っているのは、さまざまな言語を使用している人々 (特に .NET、Java、ActionScript、JavaScript など、さまざまなプラットフォームを使用している人々に API を提供する可能性が高い) からの、優れていると思われる Web API に関する意見です。例、そしてあなたが良い経験をしたこと。

私がカバーしたいいくつかのポイント：

  1. SOAP タイプのサービスと REST/RPC スタイルのサービスのどちらが好みですか? プラットフォームをサポートしている人 (.NET、Java など) は SOAP を好み、プラットフォームをサポートしていない言語を使用している人は他の言語を好むと思いますが、その仮定を検証したいと思います。

  2. API が実際に RESTful であるかどうか、または単純な古い RPC スタイルの HTTP GET/POST であるかどうかを気にしますか? もしそうなら、なぜあなたは気にしますか？API が実際に 2 つのうちの 1 つであるかどうかよりも、API がそれ自体を正しく記述している (つまり、RPC スタイルの場合は RESTful であると主張しない) ことの方が重要ですか?

  3. 誰がサービスを使用しているかを確認する必要があります。私は、パブリック識別子と、リクエストのパラメーターを検証トークンにハッシュするために使用されるプライベートトークンを使用する Amazon S3 認証を見てきました (これも flickr に似ています)。以前にこのタイプの認証を使用したことがありますか? また、どのように使いこなしましたか? 問題がある (つまり、プラットフォームでサポートされていない) ハッシュ アルゴリズムはありますか? ハッシュを HTTP ヘッダーと URI のどちらで送信しますか?

  4. バージョン管理はどのように処理する必要がありますか? 将来のバージョンを一緒に追加できるようにタイプのサブディレクトリを用意するのは良い考え/v1/ですか?それとも、リクエストのペイロードまたはクエリにバージョンを含めるなど、別のことを行いますか? 構築した API のバージョンがサポートされる期間はどのくらいだと思いますか (つまり、v2 が導入された場合、v1 の存続期間にどれくらい期待できますか)。

また、カバーする他の意見やポイントは役に立ちます。

実装している API の実際のタイプについては、意図的にあいまいなままです。人々が良い API と実装メカニズムと考えるものに関する一般的なガイダンスを探しているためです。この投稿とその回答は、より多くの人々に役立ちます。将来。

注: 検索したところ、これに関する一般的な質問が見つかりません。これらはすべて、特定の種類の API に固有のようです。ただし、重複している場合はお知らせください。また、それがコミュニティ wiki である必要がある場合 (回答者は回答の功績を認められるべきだと思うので、私はそれを作成していません)、お知らせください。そうするように変更します。

4

8 に答える 8

9

Joshua Bloch のプレゼンテーション「How to Design a Good API and Why it Matters」に興味があるかもしれません。Joshua Bloch は、「Effective Java」の著者であり、Google のプリンシパル ソフトウェア エンジニア兼チーフ Java アーキテクトです。

要約: http://portal.acm.org/citation.cfm?id=1176622

スライド: http://lcsd05.cs.tamu.edu/slides/keynote.pdf

ビデオ: http://www.youtube.com/watch?v=aAb7hSCtvGw

于 2009-01-06T07:27:05.047 に答える
5

Content-Type ヘッダーを使用した REST のバージョン管理については、http: //barelyenough.org/blog/2008/05/versioning-rest-web-services/で詳しく説明しています。

于 2009-01-04T12:18:46.707 に答える
3

Amazon が何をしているのか見てみたいと思います - http://aws.amazon.com/ - これでお金を稼いでいる連中は、明らかに他の誰よりも多くの教訓を学んでいるでしょう。

私が見ている他の A​​PI - salesforce.com と Microsoft CRM API はかなり興味深いものでした。Twitter には、強化された REST API もあります。

于 2009-01-05T13:30:56.777 に答える
3

RPC アプローチも適切なオプションです。これによりオーバーヘッドが削減され、Ice、Google Protocol Buffers、Apache Thrift などのプロジェクトにより、RPC ベースのサービスの開発が容易になります。

Web ベースの API を提供する必要がない場合は、RPC を検討することもできます。

于 2010-09-02T06:58:41.313 に答える
1

REST は、正しく行われれば、理解しやすく (HTTP をモデル化)、簡単 (リソース指向) であり、ほぼすべてのプログラミング言語 (XML) で解析できます。

于 2009-01-05T15:19:53.283 に答える
1

私見、それはすべて、提供しているアプリの種類によって異なります。重要で大規模なトランザクションを行っている場合は、SOAP (WS は「デス スター」と呼んでいます) を使用することをお勧めします。ただし、ソーシャル アプリを提供している場合は、REST を使用してください。REST の方がシンプルで、パブリック ハッキングにより適しているからです。

于 2009-01-03T22:12:41.517 に答える
0

最終的に決心できない場合は、それらすべてを実装できます。このような場合、他の人がどのようにそれを行ったかを見ることが役に立ちます。調査している 3 種類のインターフェイスを提供する Open Source XML Native Database eXistをお勧めします。

于 2009-01-04T12:49:04.197 に答える