検索
連載

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

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

PC用表示 関連情報
Share
Tweet
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行にまとめられて分かりやすくなっています。

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

 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をご確認ください。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る