Windows Azure モバイルサービスで ASP.NET Web API を試す ～とりあえずサンプル実行～

2014/6/7 .NET Backend の更新(2014/3/29) と Visual Studio 2013 Update 2 に合わせました。

2014年2月、Windows Azure モバイルサービスで、バックエンド側が .NET をサポートしました。（プレビューです）
参考：Azure: ExpressRoute Dedicated Networking, Web Site Backup Restore, Mobile Services .NET support, Hadoop 2.2, and more

.NET といっても、実質 ASP.NET Web API です。ASP.NET Web API のフレームワークと Visual Studio を生かしてバックエンド側を開発できるようになりました。

理解に手っ取り早そうなサンプルが用意されていたので、試してみました。

目次

• １．プロビジョニングとサンプルコードの入手
• ２．サンプルコードを開く
• ３．ローカルで ASP.NET Web API プロジェクトをデバッグ実行
• ４．デプロイする
• ５．ストアアプリを実行する
• ６．スケジューラーを試す
• ７．その他
  • 権限
  • カスタム API
  • データベース
  • おまけ OWIN

１．プロビジョニングとサンプルコードの入手

管理ポータルでモバイルサービスを作成します。
バックエンドを、「.NET」で選択します。

次に、データベースの設定を行い、作成を完了します。

作成したモバイルサービスの管理画面を開き、サンプルコードを入手します。
次の画像の様に、「Windows ストア」「C#」を選択してダウンロードします。

２．サンプルコードを開く

ダウンロードしたコードを Visual Studio で開きます。
ソリューション構成は、ざっと次の図のようになっています。

コードの確認

適当に２つのコードを確認します。
ASP.NET Web API プロジェクトの「Controllers」フォルダにある「TodoItemController.cs」と、
「ScheduledJobs」フォルダにある「SampleJob.cs」です。

なんか書いてあるなー程度に見ます。
「SampledJob.cs」はスケジューラーを定義しているクラスになっており、”Hello from scheduled job!”とログをとる処理が書かれています。

SampleJob.cs :

using System.Threading.Tasks;
using System.Web.Http;
using Microsoft.WindowsAzure.Mobile.Service;

namespace netmobileaoService
{
    // A simple scheduled job which can be invoked manually by submitting an HTTP
    // POST request to the path "/jobs/sample".

    public class SampleJob : ScheduledJob
    {
        public override Task ExecuteAsync()
        {
            Services.Log.Info("Hello from scheduled job!");
            return Task.FromResult(true);
        }
    }
}

３．ローカルで ASP.NET Web API プロジェクトをデバッグ実行

ローカルで ASP.NET Web API プロジェクトをデバッグしてみます。
（設定によっては、デバッグ前に NuGet でパッケージを取得する必要があります。）

イケてる感じのスタートページが表示されます。

「try it out」をクリックすると、これまたイケてる API のヘルプページに遷移します。

試しに「GET tables/TodoItem」のリンクをクリックし、右上の「try this out」をクリックします。

「Send」をクリックすると、実際に API を叩いて結果を確認することができます。最初は、EF の CodeFirst が働いて DB を生成するので、応答まで時間がかかるかもしれません。

ローカル実行の場合、DB はプロジェクトの「App_Data」フォルダ内に作成されます。

以上、ローカル実行では、ヘルプページから簡単に API やスケジューラーのデバッグが行えるよ、ということでした。

４．デプロイする

次は、デプロイです。ストアアプリの方はデプロイ後に試してみます。

ASP.NET Web API のプロジェクトを右クリックし、「発行」を選択します。

「Windows Azure Mobile Services」を選択します。

Azure へ接続するためのログイン画面がでると思うので、入力します。その後、最初に作成したモバイルサービスを選択し、「OK」をクリックします。

後は Web Deploy の方法と同じです。「次へ」をクリックしていき、「発行」をクリックするとデプロイが開始されます。

デプロイ完了するとブラウザが立ち上がり「http://***.azure-mobile.net/」にアクセスできるはずです。

補足：
デプロイ後のページから「try it out」をクリックすると、Basic 認証を要求されます。

ユーザー名は空に、パスワードはアプリケーションキーを入力します。アプリケーションキーは、Azure の管理ポータルの下にある「キーの管理」から入手できます。（ちなみに、この Basic 認証はヘルプページだけでなく API の呼び出しでも有効です。）

補足２：
TodoItemController で公開される API は、Node.js の時と同じように REST でデータを取得できます。参照 Windows Azure モバイル サービスの REST API リファレンス
ASP.NET Web API の API Controller がベースなので、「~/api/TodoItem」でも API を呼び出せます。

５．ストアアプリを実行する

デプロイ後、ストアアプリを実行してみます。
Visual Studio で、ストアアプリのプロジェクトの「App.xaml.cs」を開きます。
以下のように、Azure 上の URL と、アプリケーションキーで MobileService を生成するよう、コメントアウトを調整します。（ここでは＊＊＊で置き換えてます。）

        // This MobileServiceClient has been configured to communicate with your local
        // test project for debugging purposes. Comment out this declaration and use the one
        // provided below when you are done developing and deploy your service to the cloud.
		//public static MobileServiceClient MobileService = new MobileServiceClient(
		//	"http://localhost:59994"
		//);

        // This MobileServiceClient has been configured to communicate with your Mobile Service's url
        // and application key. You're all set to start working with your Mobile Service!
		public static MobileServiceClient MobileService = new MobileServiceClient(
			"https://＊＊＊.azure-mobile.net/",
			"＊＊＊"
		);

ストアアプリのプロジェクトを、スタートアッププロジェクトに設定し、デバッグを実行します。

すると、こんな風に↓ TodoItem を追加したり削除できたりします。

６．スケジューラーを試す

サンプルではスケジューラーのコードも用意されています。
デプロイ後、管理ポータルでスケジューラーを開きます。

「スケジュールされたジョブを作成します」をクリックし、次のように入力します。

ジョブ名「Sample」は、先ほどの ASP.NET Web API の「SampleJob.cs」の Sample です。
作成後、「一度だけ実行する」をクリックし、ジョブを実行します。

先ほど、「SampleJob.cs」の中身を除き、”Hello from scheduled job!”とログを取っていることを確認しました。ダッシュボードのログを開くと、確かにそのようにログが残っています。

サンプルのお試しは以上です。

７．その他

権限

Node.js では、API の権限を次のように設定できました。

ASP.NET Web API では、API コントローラーのメソッドに次の属性を付けます。（Microsoft.WindowsAzure.Mobile.Service.Security 名前空間）

[RequiresAuthorization(AuthorizationLevel.User)]

AuthorizationLevel は、Anonymous／Application／User／Admin を選択できます。

この属性の付与のルールは ASP.NET Web API のルールと同じで、グローバル／コントローラー／アクションメソッド というレベルで付与できます。

カスタム API

Node.js では、管理ポータルからカスタム API を定義していました。.NET では、ASP.NET Web API の仕組みを生かして任意の API を定義できます。こんな風に↓

public class ValuesController : ApiController
{
	public string Get()
	{
		return "Hi-!";
	}
}

Node.js で「~/api/****」で呼び出せたように、ASP.NET Web API でも「~/api/***」で呼び出せます。

データベース

サンプルでは、データベースとの接続に Entiry Framework を使っていますが、どのような ORM でも使用できます。これは、通常のサーバー側開発と同じように考えて構わないと思います。

ただ注意が１つあります。Node.js ではクライアント側からカラムを新たに定義すると、DB もそれに合わせてカラムを自動生成していました。が、.NET では サーバー側、つまり ASP.NET Web API 側でもカラムの定義が必要です（ASP.NET Web API のルールに沿う）。Node.js はクライアント側主導で開発しやすいのに比べ、.NET ではバックエンドを通常のサーバー開発と同じ様に開発できる、というのが強みです。

恐らくサンプルで Entity Framework のコードファーストが選択されているのは、ちょっとでも Node.js に合わせて利用しやすくするためなのかもしれません。（そんなことはないんでしょうけど）

おまけ OWIN

この .NET Backend は OWIN アプリケーション + Microsoft.Owin.Host.SystemWeb で動きます。「WebApiConfig.cs」に記述されている「ServiceConfig.Initialize...」で、OWIN パイプラインに ASP.NET Web API や認証コンポーネント（Katana）を登録しています。

「ServiceConfig.Initialize...」がモバイルサービスに必要なものを全てセッティングしてくれる、というイメージです。ヘルプページの提供や、ScheduledJob が API コントローラーじゃないのに API で呼び出せるわけ、などといったものは全てこれによる働きです。

「WebApiConfig.cs」を呼び出すのは、Azure 上で適用されるモバイルサービスランタイムの「Global.asax.cs」です。なので Azure 上では ASP.NET Web API プロジェクトにある「Global.asax.cs」は適用されないので注意。また、「WebApiConfig.cs」のクラス名やメソッド名を変更しても動きません（ある規約に従う必要があります）。

このあたりは Windows Azure モバイルサービスの .NET バックエンドの仕組みを簡単に調べてみた をご参考下さい。