私は完全に ajax ベース (POST なし) の単一ページ Web アプリに取り組んできましたが、現在は開発中に Web サービスに ASMX を使用しています。Web サービスは JSON データを処理します。リリースのために、WCF または WebAPI にアップグレードする必要があることはわかっています。
最終的には、Web アプリと同じ Web サービスで動作するネイティブ モバイル アプリケーションを構築する予定です。すべてが等しい場合、2 つのどちらかを選択する必要がある場合、Web サービスがさまざまなクライアント アプリと連携できるようにするには、どちらのオプションを使用すればよいでしょうか?
ありがとう。
アプリケーションがさまざまなプラットフォームのモバイル デバイスからのみアクセスできるように設計されている場合、これらすべてのプラットフォームに共通する最も簡単な分母を見つける必要があります。つまり、相互運用性に関心がある場合は、すべてのプラットフォームで使用できる 1 つの独自の通信テクノロジに焦点を当てることになります。
JSON + REST は、今日の多くのプラットフォーム (もちろんモバイルも含む) の共通の最も簡単な分母のようです。そして、それが実装する唯一の通信テクノロジである場合、WebAPI は当然の選択のようです。
WCF はより拡張性があり、より構成可能であり、さまざまなバインディング、さまざまなエンコーディングをさまざまなプロトコルでプラグインでき、SOAP、WS-* を実装し、(慎重に選択されたバインディングを使用して) 非常に高速であり、JSON+REST も実行できます。 、しかし、そのすべての機能は必要ありません (また、これらすべての機能のために WCF も非常に複雑になる可能性があります)。必要なのは遍在性とシンプルさです。あなたの要件を考えると、私は WebAPI を選択します。
私はWCFを使用して一連のRESTfulWebサービスを開発し、最近、WCFをASP.NETWebAPIに置き換えるプロジェクトを開始しました。私の経験では、ASP.NET Web APIはWCFよりも習得が容易で、操作も簡単です。また、ASP.NETWebAPIを選択する理由をいくつか挙げることができます。
WCFURLには「.svc」拡張子が含まれています。例： http://localhost/MyRestService.svc/。これはクライアントに問題を引き起こすことはないはずですが、醜いです。.svcIIS URL Rewriteモジュール（このブログ投稿を参照）を使用して拡張機能を取り除くことができますが、ASP.NET Web APIを使用すると、そもそも問題は発生しません。
WCFはを使用しDataContractJsonSerializerます。これは、クライアントにとって問題となる可能性のあるJSONを生成します。具体的な例としては、日付や辞書などがあります。WCFで使用されるシリアライザーを変更できますが（このSOの質問を参照）、ASP.NET Web APIはデフォルトでJSON.NETを使用します。これは、高度に構成可能です。
今日から始めて、新しいRESTful Webサービスを作成する場合、WCFではなくASP.NET Web APIを選択するのは、これが設計された目的であるため、簡単な選択です。