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

» 2013年06月20日 18時00分 公開
[長谷川智之ビーブレイクシステムズ]
前のページへ 1|2|3       

実装上の問題点(クライアントサイド)

 「では、実際にRESTfulなシステムを構築してみよう」と思わせてしまったかもしれませんが、実は問題があります。

 というのも、現在のWebブラウザではHTMLのFORMタグのmethodは「GET」と「POST」のみ許可していて「PUT」や「DELETE」を標準でサポートしていないものがほとんどだからです。なのでRESTfulになるようシステム設計を忠実に守ろうとした場合、現状ではJavaScriptを用いて「PUT」や「DELETE」を送信するなどの手段を取らなければいけません。

 ここからは、Play frameworkが用意しているJavaScriptライブラリより「PUT」や「DELETE」の送信方法を見てみましょう。

jQueryを使った例

 Play frameworkでは「public」フォルダの下の「javascripts」フォルダにJavaScriptライブラリの「jQuery」が用意されています。

 jQueryの細かい使い方については、ここでは割愛します。jQueryについて詳細を知りたい方は@ITの記事を参照してください。

 ここでは、簡単に「PUT」を送る例を下記に示します。

  1. <!DOCTYPE html>
  2. <html>
  3. <head>
  4. <!-- 【1】 jQueryライブラリの呼び出し -->
  5. <script type="text/javascript" src="@routes.Assets.at("javascripts/jQuery-1.7.1.min.js")" ></script>
  6. <script type="text/javascript">
  7. function doPUT(){
  8. $(document).ready(function(){
  9. // 送信先のURL の取得
  10. var targetURL = getTargetURL();
  11. // Formデータの取得
  12. var formData = getFormData();
  13. // 【2】 「PUT」送信
  14. $.ajax({
  15. type: 'PUT', // HTMLメソッド
  16. url: targetURL, // 送信先のURL
  17. data: formData, // 送信するデータ
  18. success: function(){ // 送信成功時の処理
  19. alert('成功しました。');
  20. }
  21. });
  22. });
  23. }
  24. function getTargetURL(){
  25. ……略
  26. }
  27. ……略
  28. </script>
  29. ……略
  30. </head>
  31. <body>
  32. <form method="POST">
  33. …… 略
  34. <!-- 【3】JavaScriptの呼び出し -->
  35. <input type="submit" value="更新" onClick="javascript:doPUT();"/>
  36. </form>
  37. </body>
  38. </html>

 簡単に上記のポイントを説明していきます。

  • 【1】jQueryライブラリの呼び出し

 Play frameworkで用意されているjQueryを宣言します。jQueryのバージョンについてはPlay frameworkによって変わることがあるので注意してください。

  • 【2】$.ajaxメソッド

 Ajax通信を行うメソッドです。TypeにHTMLメソッドを指定します。今回は「PUT」メソッドを使ってFormデータを指定したURLに送信しています。

  • 【3】JavaScriptの呼び出し

 ボタンを押したときにJavaScriptのdoPUT()メソッドを呼ぶようにしています。

 このように、JavaScriptなどの技術を用いて「PUT」や「DELETE」などWebブラウザがデフォルトで対応していないHTMLメソッドを送信できることはできます。

 しかし「PUT」や「DELETE」などを呼ぶためだけにJavaScriptを使うなどの手間が発生してしまいます。全体的にうまく設計しないと、このような余計な手間は開発効率も悪くなりますし、バグが発生する可能性が高くなります。

 ですので、RESTの原則から外れてしまいますが、個人的には更新や削除も「POST」で更新や削除のフラグを渡すなどで行う方が現実的かと思います。

実装上の問題点(サーバサイド)

 これで、頑張ればクライアントから「PUT」や「DELETE」の送信をできることは分かりましたが、まだ問題があります。

 それは、サーバによっては「GET」「POST」以外のHTMLメソッドを受け付けない設定になっている場合があることです。この場合、クライアントでどんなに頑張っても、サーバ側で拒否されてしまうので、「GET」「POST」送信で更新や削除の処理を行うのは仕方がないと思っています。

 ですので、最初のRESTでの説明では「GETやPOSTで読み込みや更新や削除など全てやってしまうシステムはREST的ではありません」と書きましたが、現状、この「PUT」「DELETE」送信に関してはRESTfulでない方がより良い解決策かと思います。

 無理にサポートされていないHTTPメソッドを送信するための無駄な処理を追加する必要がなくなるので、「PUT」や「DELETE」の代わりに「POST」での送信の方が良いでしょう。イメージとしては以下の2つの送信方法を分ける方が現実的かと思います。

  • 「GET」はリソースの指定もしくは検索などリソースに変化を与えない処理
  • 「POST」はリソースの変更、追加、削除などリソースの状態を変える処理

次回はPlay frameworkで行う“テスト”について

 さて、最後に現状のWebブラウザでのHTTPメソッドに対する制限があり、完全なRESTfulなシステムのは現実的ではないことも分かりましたが、それを差し引いてもRESTはシステムアーキテクチャのパターンとしてはシンプルで使いやすいパターンであるかと思います。

 今回はPlay frameworkが得意とするRESTの利点を生かしたシステム構築パターンについて学びました。次回はPlay frameworkで行うテストについて紹介しますので、楽しみにしてください。

著者プロフィール

長谷川 智之(はせがわ ともゆき)

2008年より、株式会社ビーブレイクシステムズに在籍。

基本的にはどんな問題があるか分からない新しい技術より、問題点をクリアした使い慣れた技術の方を好む保守派。しかし、最近のヤングでナウな新世代の考えに乗り遅れてきたため、新しい技術にも手を出し始める

前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

Java Agile 記事ランキング

本日月間

注目のテーマ

4AI by @IT - AIを作り、動かし、守り、生かす
Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。