最高のSOAP / REST / RPC Web APIの例は？そして、なぜあなたはそれらが好きですか？そして、それらの何が問題になっていますか？
私の会社では、データにアクセスして更新するためにWeb APIに分岐し始めています。最初はパートナー向けですが、将来は一般に公開される可能性があります。現在のところ、APIの外観（SOAP、REST、RPCなど）は完全にオープンであり、まだ何も決定していません。そのため、人々が良いと思うWeb APIの両方の例と、あなたが考える理由に興味がありますそれ。
私が興味を持っているのは、あなたが良いと思うWeb APIについて、さまざまな言語を使用している人々（特に.NET、Java、ActionScript、JavaScriptを含む多数のプラットフォームを使用している人々にAPIを提供する可能性が高い）からの意見です。例、そしてあなたは良い経験をしました。
私がカバーしたいいくつかのポイント：
SOAPタイプサービスまたはREST/RPCスタイルのものを好みますか？プラットフォームサポート（.NET、Javaなど）を持つ人はSOAP ones andプラットフォームがサポートされていない言語を使用している人は他の言語を好むでしょうが、その仮定を検証したいと思います。
APIが実際にRESTfulであるか、それとも単純な古いRPCスタイルのHTTP GET/POSTであるかを気にしますか？もしそうなら、なぜあなたは気にしますか？ APIが実際に2つのうちの1つであるかどうかよりも、APIがそれ自体を正しく記述する（つまり、RPCスタイルである場合はRESTfulであると主張しない）ことが重要ですか？
誰がサービスを使用しているかを確認する必要があります。私は、リクエストのパラメーターを検証トークンにハッシュするために使用されるパブリックIDとプライベートトークンを使用するAmazon S3認証を見てきました（これもflickrに似ています）。このタイプの認証を以前に使用したことがあり、どのようにしてそれを手に入れましたか？問題がある（プラットフォームでサポートされていない）ハッシュアルゴリズムはありますか？ハッシュをHTTPヘッダーまたはURIのどちらで送信しますか？
バージョン管理はどのように処理する必要がありますか？
/v1/タイプサブディレクトリ。将来のバージョンを一緒に追加できるようにします。または、リクエストのペイロードまたはクエリにバージョンを含めるなど、別の方法で行いますか？ビルド対象のAPIのバージョンがサポートされると予想される期間（つまり、v2が導入された場合、v1の存続期間の予想はどのくらいでしょうか）。
また、カバーする他の意見やポイントは役に立ちます。
人々が優れたAPIと実装メカニズムであると考えるものに関する一般的なガイダンスを探しているため、私は実装している実際のタイプのAPIについて意図的に曖昧にしています。そのため、この投稿とその回答はより多くの人々に役立つでしょう将来は。
注：検索したところ、これに関する一般的な質問は見つかりません-それらはすべて、特定のタイプのAPIに固有のように見えますが、それが重複している場合は、お知らせください。コミュニティウィキである必要がある場合もお知らせください（私は人々が答えのために信用を得るべきだと思うので私はそれを作りませんでした）そして私に知らせてくださいそしてそれをそうなるように変更します。
これが私の見解です。
Javaの観点から来ていますが、私は実際にはRESTを好みます。SOAPエンベロープは複数の名前空間を持ち、その複雑な構造は忌まわしいです。それはほとんど架空の問題を解決しようとします、効率的に何も解決しません。SOAPについて唯一知っていることは、認証とエラーの標準があることです。一方、両方を4つ含めることで、はるかに簡単に解決できます。ルートXML要素の標準属性-ユーザー名、パスワード、errorCode、errorDescription。
重要なのは、APIの説明とドキュメントが優れていることです。成熟したフレームワークにおけるRESTとSOAPの違いは、ほとんど数行の構成にあります。
SOAPの場合は、SOAPセキュリティの一部としてハッシュを送信します。RESTの場合は、すべてをペイロードにパッケージ化し、認証にHTTPヘッダーを使用しないようにします。ただし、主観的な理由しかありません。 HTTPヘッダーを簡単に公開しないフレームワーク。
私の個人的な好みは、プロトコルバージョンごとに異なるURIを使用することです。私の経験では、これにより、新しいバージョンでの柔軟性が高まり、サポートされていないバージョンのプロトコルに接続する古いクライアントは、明白な理由ですぐに機能を停止します。また、古いバージョンのアプリケーションを古いURIにマッピングして、新しいサーバーバージョンでレガシーサポートコードを使用しないようにすることもできます。
古いバージョンのプロトコルをサポートする期間については...理想的には、それを使用するクライアントがある限り。これは技術的な決定よりもビジネスです。少なくとも1つの以前のプロトコルバージョンをサポートする必要があります。通常、レガシーサポートコストを削減するためにクライアントを新しいバージョンに向けてプッシュすることに関心があります。クライアント側から見ると、新しいバージョンは新しい機能、より良いプロトコル、およびある種の追加のビジネスインセンティブ（新しい機能だけでは十分でない場合）を意味するはずです。
Joshua Blochのプレゼンテーション「優れたAPIを設計する方法と重要な理由」に興味があるかもしれません。 Joshua Blochは「Effective Java」の作者であり、プリンシパルソフトウェアエンジニアであり、チーフJava Googleのアーキテクトです。
要約： http://portal.acm.org/citation.cfm?id=1176622
REST Content-Typeヘッダーを使用したバージョン管理は、ここで十分にカバーされています： http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ =
RPCアプローチも適切なオプションです。オーバーヘッドを削減し、Ice、Google Protocol Buffers、Apache Thriftなどのプロジェクトにより、RPCベースのサービスの開発が容易になります。
WebベースのAPIを提供する必要がない場合は、RPCも検討したい選択肢です。
私はアマゾンが何をしているのかを理解します- http://aws.Amazon.com/ -このことからお金を稼ぐ人たちは明らかに誰よりも多くの教訓を学んだでしょう。
私が見てみたい他のAPI-salesforce.comとMicrosofts CRM APIはかなり興味深いものでした。 Twitterは戦いを強化していますREST apiも。
私見、それはすべてあなたが提供しているアプリの種類に依存します。重要で大きな時間のトランザクションを実行している場合は、必ずSOAP（WS "death star"と呼ばれています）を使用してください。ただし、ソーシャルアプリを提供している場合は、RESTを使用してください。シンプルでパブリックハッキングに適しているからです。
RESTは、正しく実行されれば、理解しやすく（HTTPをモデル化）、簡単（リソース指向）であり、ほとんどすべてのプログラミング言語（XML）で解析できます。
最終的に決断できない場合は、それらすべてを実装できます。これらの場合、他の人がそれをどのように行ったかを調べることは有用です。オープンソースXMLネイティブデータベースをお勧めします eXist それは種類のインターフェイスを提供するあなたが証明していることです。