他のアプリケーションへのサービスを準備するために、メディアサービスを作成する必要があります。問題は、APIをRESTまたはSOAPにする必要があるということです。
私はこれら2つの方法を比較する多くの記事や資料を読みました。誰もがそれらの1つを使用することについて独自のアイデアを持っています。誰もが製品をRESTに切り替えるため、SOAPの代わりにRESTを使用することをお勧めします。しかし、重要なのは製品の目的であり、石鹸とRESTのどちらかを選択できるという目的に基づいていると思いました。
私たちのサービスはユーザーとのやり取りはありません。ローカルアプリケーションで動作するだけで、APIがシンプルで便利であることが重要です。私が言ったように、このサービスは他のアプリにメディアの保存と管理をもたらします。私は石鹸と休息の両方の経験がありますが、今回はどちらかを選ぶことができません。
それであなたの考えは何ですか？SOAPまたはREST？このタイプのプロジェクトでは実際に！
私は行きたいと思います REST-それはより単純で、より少ないオーバーヘッドを追加します。また、リソースが明確に定義され、区切られると、開発者は、ドキュメントを必要とせず、オブジェクトインターフェイスの作成を待たずに、APIエンドポイントと対話する方法をすでに知っています。
私は間違いなくSOAPよりもRESTを選択しますが、少なくともJavaとC＃の世界では、WSDLタイプを適切なタイプに自動的にマップする既存のウィザードを考えると、消費者の観点からは、SOAPの方が操作が簡単です。
RESTの操作が簡単であることは非常に欺瞞的です。これはオープンスタンダードであり、SOAP Webサービスとは異なる方法でHTTPプロトコルを活用する、はるかにクリーンです。RESTはすべての人のビジネスに適合しないため、特にすでに何かがある場合は、それを理解する必要があります。
とはいえ、Webがどのように機能するかを本当に知りたい場合は、人々が使用している標準に近づき、RESTで不要なコードを大量に作成するウィザードに依存することは少なくなります。
間違いなくREST。
私はプロトコルとRESTの両方を使用してAPIを作成しましたが、消費者にとってははるかに簡単で、はるかに柔軟です。
Googleはほぼ4年前にSOAPのサポートを停止し、現在はRESTとJSONのみを使用しています。
必要なデータのみを取得するRESTの「部分的な応答」は巨大です。
優れたRESTAPIの作成に関する便利なドキュメントは次のとおりです。http： //info.apigee.com/Portals/62317/docs/web%20api.pdf