Playで体得するRESTfulアーキテクチャの基礎知識：Javaの常識を変えるPlay framework入門（5）（2/3 ページ）

サーブレット／JSPを基にする重厚長大なJavaのWeb開発のイメージを変える軽量フレームワーク「Play」について解説し、Webアプリの作り方を紹介する入門連載。今回は、RESTの概要、URIの概念、RESTで使われるHTTPメソッドとステータスコード、PlayでのRESTfulな設計、実装上の問題点などを解説します。

[長谷川智之，ビーブレイクシステムズ] PC用表示関連情報

LINE

Hatena

前のページへ | 次のページへ

RESTで使われるHTTPメソッドとステータスコード

　現在、世の中に出回ってるWebシステムで使われているHTTPメソッドはGETもしくはPOSTで画面遷移から情報の更新や削除まで全て賄っているものがほとんどかと思います。

　実際JSPとServletのWebシステムがはやり始めたころはdoGetもしくはdoPostメソッドのみの解説だった記憶があります（これはWebブラウザの制限もあるのですが、この制限については後述します）。

　しかしHTTPメソッドはGETやPOST以外にもあり、それぞれのメソッドには意味があります。特に、RESTで使われると思われる主なHTTPメソッドは以下の4つです。


HTTPメソッド	用途
GET	リソースの取得（リソースに対する変更は行わない）
POST	リソースの新規追加
PUT	リソースの更新
DELETE	リソースの削除

　なので、例えば以下のようにGETでパラメータを渡して削除を要求して実行するようなシステムはREST的ではありません。

http://……/doAction?category=delete

　また、HTTPでは処理に対する返答のステータスコードも定義されています。よくWebブラウザのURIを間違って入力した際に表示される「404 Not Found」も定義されているステータスコードの一例です。大まかな定義は以下のようになります。


200番台	正常時のコード。
300番台	リダイレクト時のコード
400番台	クライアント側でのエラー時のコード
500番台	サーバ側でのエラー時のコード

　以下、代表的なステータスコードを挙げておきます。


ステータスコード	意味
200	OK。正常時のレスポンス
302	Found。リダイレクトする時のレスポンス
401	Unauthorized。承認失敗時のエラー
403	Forbidden。不正なアクセス時（権限がないなど）のエラー
404	Not Found。指定したURIにリソースがない時のエラー
408	Request Timeout。タイムアウト発生時のエラー
500	Internal Server Error。サーバで発生した予期せぬエラー
503	Service Unavailable。サーバがメンテナンスや高負荷などでリクエストを受け付けられない状態

　RESTではリクエストの処理結果を定義されているリクエストコードに沿って返すことを原則としています。

Play frameworkでのRESTfulなシステム構築

　さて、ここまでRESTについて紹介してきて、何かピンと来たものはないでしょうか？ HTTPメソッドやURI設計などは本連載の前回記事で出てきた「routes」ファイルできれいにまとまる気がしませんか？

RESTとroutesファイル

　例えば今回の例に挙げたブログサイトなどをroutesファイルでまとめてみると、下記のようになります。

GET /    controllers.Application.showAllList() ……【1】
GET /list/:year    controllers.Application.showYearList(year:Integer) ……【2】
GET /list/:year/:month    controllers.Application.showYearMonthList(year:Integer,  month:Integer) ……【3】
GET /list/:year/:month/:day   controllers.Application.showYearMonthDayList(year:Integer, month:Integer, day:Integer) ……【4】
GET /entry/:id    controllers.Application.showBlog(id:Long) ……【5】
GET /new    controllers.Application.showEditNewBlog() ……【6】
POST /new    controllers.Application.insert() ……【7】
GET /edit/:id    controllers.Application.showEditBlog(id:Long) ……【8】
PUT /edit/:id    controllers.Application.update(id:Long) ……【9】
DELETE /edit/:id    controllers.Application.delete(id:Long) ……【10】

※ 前回の記事でも紹介しましたがPlay frameworkでは「/xxx」と「/xxx/」は別物とみなされます。もし最後のスラッシュの有無にかかわらず同じリソースを指す場合は両方とも定義する必要があります。

　上記のroutesファイルは以下のことを表現しています。

【1】ルート（/）は全ての記事を表示
【2】URIで指定した年の記事を表示
【3】URIで指定した年月の記事を表示
【4】URIで指定した年月日の記事を表示
【5】URIで指定したエントリーID記事を表示
【6】最新の記事の編集画面を表示
【7】最新の記事を登録
【8】URIで指定したエントリーIDの記事を編集画面に表示
【9】編集画面の内容を更新
【10】編集画面の記事を削除

　前回の記事でも説明しましたがroutesファイルでは以下のことが1行にまとめられて分かりやすくなっています。

リクエストの種類
URI
その処理を行うメソッド

　GETでは表示を表し、POSTで登録を表し、PUTで更新を表し、DELETEで削除を表しているところがポイントです。

　また、このパターンに従うとGETとその他を区別することによって、URIを入力しただけで本来は画面から行うことが前提の処理を防げるのもポイントの1つです。例えば【6】と【7】の場合と、【8】と【9】と【10】の場合になります。

RESTとResultsクラス

　今度は結果について見てみましょう。前述で、RESTではリクエストの処理結果を定義されているリクエストコードに沿って返すことを原則としていると書きましたが、Play frameworkでは、そのステータスコードに対応するものとしてResultsクラスを用意しています。このResultsクラスではステータスコードに該当するResults.Status（リダイレクト時がResult）を返すメソッドを用意しています。

　これまでの本連載で、サンプルのControllerでよく記述していた下記のような処理が、それに該当します。実はControllerクラスは Resultを返すメソッドを用意したResults クラスを継承してます。

public static Result showSomething() {
    …… 略
    return ok(……);
}

　先ほど挙げたステータスコードに対応するResultsクラスのメソッドは以下のようになります。


ステータスコード	戻り値	メソッド
200	Results.Status	ok()
302	Result	found()
401	Results.Status	unauthroized()
403	Results.Status	forbidden()
404	Results.Status	notFound()
500	Results.Status	internalServerError()

　また任意のステータスコードを返せるメソッドも用意されています。

static Results.Status status(int status)

　ここでは一番シンプルなメソッドを選び紹介しましたが、他のステータスコードに対応したメソッドやさらに詳細を知りたい方はPlay frameworkのAPIをご確認ください。

実装上の問題点（クライアントサイド／サーバサイド）