ASP.NET Web APIの全体像をつかむ：連載：ASP.NET Web API 入門（1/2 ページ）

連載目次

ASP.NET Web APIとは

　「ASP.NET Web API」とは、ブラウザや、デスクトップ・アプリケーションから、タブレットや携帯電話などのモバイル・デバイスまで、さまざまなクライアントにHTTPサービスを提供するためのフレームワークだ。2012年8月に、.NET Framework 4.5、ASP.NET MVC 4とともにバージョン1（＝ASP.NET Web API）として正式版がリリースされた。

　「One ASP.NET」のビジョン（＝ASP.NETをコアとしたHTTPサービス構築テクノロジ全体を示す概念）の下、「サービス」を提供するフレームワークとしてSignalRとともに提供されている（「サービス」のほかに「Webサイト」用のフレームワークとして、ASP.NET Webフォーム（Web Forms）、ASP.NET Webページ（Web Pages）、ASP.NETシングル・ページ・アプリ（SPA： Single Page Apps）、ASP.NET MVCも提供されている。次の図を参照）。

One ASP.NETの概念図

　ASP.NET Web APIのパッケージは、NuGetで公開されており（リンク先の［Version History］欄から任意のバージョンを選択可能）、.NET Framework 4以上であればASP.NET WebフォームやASP.NET MVCのほかのフレームワークと一緒に利用可能だ（※執筆時点では、正式版がリリースされているバージョン1に限る）。またソース・コードは、CodePlexにて、ライセンスApache License 2.0で公開されている。

　バージョン1というと、未熟なフレームワークと思われがちだ。例としてASP.NET MVCは、バージョン1と2を経て、3でようやく優れたフレームワークとしての機能を備えた。だが、ASP.NET Web APIは違う。バージョン1にも関わらず、機能性、柔軟性、拡張性が高く、かつ、軽量で洗練されたフレームワークとなっている（※HTTPサービスを構築することに限った話であり、「ほかのフレームワークに勝る」という意味ではない）。

　また、2013年7月現在では、すでにバージョン2（＝NuGetにおける「Microsoft ASP.NET Web API 5.0.0」というバージョン表記のものが「ASP.NET Web API 2」に該当）のベータ版が公開されており、属性ベースのルーティングや、OWIN（Open Web Interface for .NET）（＝サーバとWebアプリをつなぐ共通インターフェイス。PythonのWSGI、RubyのRackに相当）への対応など、次々と補完されていくフレームワークの進化に目が離せない。

　このようなASP.NET Web APIだが、登場してからすでに1年近くたつ。しかし、いまだにその必要性や使い方がよく分からないという人も少なくないのではないだろうか？

　そこで本連載では、ASP.NET Web APIを基礎から一通り解説する。

　本稿の第1回目である今回は、「登場の背景」と「ASP.NET Web APIが何者であるか」を説明し、最後に「Hello, World」としてVisual Studioに組み込まれているプロジェクト・テンプレート（により自動生成されるひな型コード）を基に、コーディングについて解説する。本稿で、ASP.NET Web APIの全体像をつかんでいただければ幸いだ。

登場の背景

　今、HTTPサービスがますます重要になっている。スマートフォンやタブレットなどのモバイル・デバイスが次々と登場する昨今、多くのアプリケーションは、各デバイス間でデータを共有するためにHTTPサービスを利用する。往来のデスクトップ・アプリケーションやWindowsストア・アプリなどのPC上で動くアプリケーションも例外ではなく、オンライン・コンテンツ対応にシフトすることも少なくはない。

　ブラウザも目的は違うが同様だ。リッチなインターフェイスを提供するために、HTTPサービスを使ってデータを取得し、ブラウザ側で描画する。これら多種なクライアントで利用されるHTTPサービスだが、クライアントごとに構築することは、困難を極めるだろう。

　だが、.NET Frameworkが登場してから現在に至るまで、ASP.NET WebサービスやWCFサービスなど、さまざまなサービス・フレームワークが登場しているが、多種なクライアントに対応するための機構は用意されていなかった。こうした背景から、ASP.NET Web APIは登場した。

　往来のフレームワークとASP.NET Web APIの大きな違いは、ASP.NET Web APIがHTTPに準ずるフレームワークであることだ。TCPやMSMQなどのいくつかのトランスポート・プロトコルをサポートするWCFとは違い、ASP.NET Web APIはHTTPを対象とする。では、HTTPに準ずると何が良いのか？

　HTTPを活用することは、RESTfulなHTTPサービスを構築することにつながる。URIでリソースを表し、HTTPメソッドでリソースをどのように操作するかを指定する。クライアントは、要求するメディア・タイプをHTTPヘッダ（AcceptやContent-Typeなど）で表し、提供側は要求に沿うメディア・タイプを選択してデータを提供する。これらの機能はASP.NET Web APIにとってはおはこだ。複数のクライアントがそれぞれ自身で適切なメディア・タイプを選択したとしても、クライアントごとにHTTPサービスを用意する必要はない。ASP.NET Web APIが単独で複数のクライアントに対応できるのだ。

ASP.NET Web APIはさまざまなメディア・タイプによるメッセージングに対応する

　確かにWCFやASP.NET MVCでもRESTfulなHTTPサービスを提供することが可能だ。だが、上記のように振る舞うには、（ASP.NET Web APIよりも）多くの作業が必要となる。この対応が難しいことは、ASP.NET Web APIの開発経緯からも読み取れるだろう。開発当初、（後のASP.NET Web APIとなる）次のWeb APIフレームワークはWCFをベースに開発されようとしていた（この影響により開発当初は「WCF Web API」と名前が付けられていた）。だが、HTTPを柔軟に扱うためにはWCFは巨大過ぎた。このため、HTTPヘッダ、HTTPメッセージなどのHTTPを操作するためのモデル（参考：「System.Net.Http 名前空間」）をゼロから構築することを選択し、そして全く新しいサービス・フレームワークとして、ASP.NET Web APIが開発されることになった。

　以上の経緯よりASP.NET Web APIは、さまざまなクライアントにRESTfulなHTTPサービスを提供するフレームワークとして鎮座している。もちろん適材適所で、WCFなどの既存のサービス・フレームワークを選択した方がよい場合もあるが、RESTfulなHTTPサービスを構築したいときは、ASP.NET Web APIを使うのが最適だろう。

ASP.NET MVCとの関係

　次に、誤解しやすいであろう、ASP.NET MVCとの関係について解説する。

ASP.NET Web APIは、ASP.NET MVC 4とともに正式版がリリースされた。そのため、Visual Studio 2012（Update2）でASP.NET Web APIプロジェクトを作成するには、次のように操作を行う。（メニューバーの）［ファイル］メニューの［新しいプロジェクト］から、プロジェクト・テンプレート［ASP.NET MVC 4 Web アプリケーション］を選択する。次に、開かれたウィザードで、［基本］［インターネット アプリケーション］［Web API］［シングル ページ アプリケーション］の中から、［Web API］を選択する。

　このようにASP.NET Web APIのプロジェクトは、ASP.NET MVC 4 Webアプリのプロジェクト・テンプレートからプロジェクトを作成する。また、ASP.NET Web APIのアーキテクチャの説明をのぞくと“コントローラ”“ルーティング”“モデル・バインディング”“フィルタ”“IoC（Inversion of Control： 制御の反転）”といったASP.NET MVCと同じキーワードが登場する。なるほど、こういう状況なので「ASP.NET Web APIは、ASP.NET MVCから派生、もしくは子に当たるフレームワークか？」と思ってしまうのも仕方がない。

　だが違う。ASP.NET Web APIは先ほども述べたとおり、ASP.NET MVCなどに全く依存しないフレームワークである。そして、ASP.NET Web API単独で、ASP.NET MVCやSignalRと並ぶOne ASP.NETの柱の1本となっている。

　ASP.NET MVCからの派生だと認識されるのは、ASP.NET Web APIはASP.NET MVCのアーキテクチャを参考にして作られたことが要因だ。もちろんアーキテクチャが類似することによるメリットもある。特にルーティングは、RESTfulなサービスを提供することにとても有効な機能である。ほかにも、リクエストやレスポンスを扱うコントローラやIoCコンテナによる拡張性の高さなど（ASP.NET MVCと類似するアーキテクチャ）は、開発作業の効率に素晴らしい効果を与えている。

　しかし注意点もある。それは、使用するコンポーネントが（両者で）全く違うということだ。

　例えばコントローラやフィルタ、モデル・バインディングの機能を提供するフレームワークのコアに当たるコンポーネントは、ASP.NET MVCでは「System.Web.Mvc名前空間」に配置されているのに対し、ASP.NET Web APIでは、「System.Web.Http名前空間」に配置されている。

　もちろん、細かい動作も異なってくる。例えば、ルーティングの動作は、ASP.NET MVCではアクション名が主であるのに対し、ASP.NET Web APIはHTTPリクエストのメソッドが主となる。

　バージョン1にも関わらず、洗練されたフレームワークであることの理由には、このASP.NET MVCのアーキテクチャを参考にしていることが含まれるだろう。

　「名前空間や動作が違う」ということを意識していれば、開発に影響が出るような大きな落とし穴にははまらずに済むだろう。むしろ、ASP.NET MVCの経験がある開発者にとっては、とてもなじみやすいフレームワークであるといえるだろう。