RESTfulな問い合わせフォームが笑えるほど簡単に作れた件
いまさらですが自社システムで初めてRESTを使ったインターフェイスを実用化。 簡単なイベント申し込みフォームですが、簡単な小物だからこそRESTが最適。 明快なルールでパラメータを渡せば、明快なルールで答が返ってくる。気持ちよすぎて笑えます。
Contents
とにかく実用化して試してみた
このたび初めて、RESTを実用化してみました。
いまさらながらRESTです。
RESTって、
ずいぶん簡単で取っつきいいんで、
早くどっかで使いたい遊びたい試したいと思いつつ、
いまごろになってしまいました。
当社のメインであるCachéのシステムが、
RESTに対応したのがバージョン2016.2以降ということで、
２年前までは使えなかったわけでして。
遅くなった言い訳はそれ。
で、
何に使ったかというと、
名前とメールアドレスだけを入れたら済むような、
実にシンプルなイベント参加申し込みフォームですね。
入力項目は他にもいくつかあるんですけども、
現物はこのページの下のほうです。
https://www.m-tone.co.jp/79/realgenius_next.htm
メルマガの申し込みフォームとかにもよくある、
いくつかの項目を埋めて送信ボタンを押すだけっていうパターン、
いわゆる「お問い合わせフォーム」みたいなもん。
入力結果がメールで運営者に送られ、
本人にも自動で確認メールが返信される。
たったそれだけのことなんで、
とにかく簡単な開発作業で終わらせたい。
で、
実際にやってみると、
やっぱり直感的に想像したとおり、
笑えるくらい簡単でした。
サーバにアクセスのは一瞬だけで、
ライセンスも一瞬しか食わないし。
シンプルで明快で抜群です。
これからもRESTで片づくことならバンバン使っていきたいし、
RESTには向いてない処理であっても無理からでもRESTfulにやってしまいたい。
そんな気さえする軽快さでした。
RESTとは何か
REST（REpresentational State Transfer）とは、
××××××の○○○○○○○○○
です！
‥‥と、
すっきり言い切れたらいいんですが、
でもこれ、
ちょっとややこしいっぽい。
Roy Fieldingって人、
HTTPプロトコル規格の主要著者の一人だというから、
相当えらい人っぽいのだが、
その人が
２０００年に発表した博士論文の中で
RESTっていう造語を初めて使ったということがわかった。
どうも途中から意味も変わってきているようなのですが、
はじめはどうやら、
複数のアーキテクチャスタイル（制約）
のことだったようだ。
‥‥？？
ま、ひとことでいうと
制約
なんです。
こういう場合はこうしなさい、
そんな場合にはこうすることにしましょうか、
みたいな、
どんなときにどうしましょうっていう、
設計原則の集合体なわけですね。
いろんな人たちが別々につくった複数のソフトウエアを連携させるには、
一定の思想が必要になりますからな。
アーキテクチャーに関する制約なり原則なりを集めたもの
と
解釈してまちがいないでしょう。
一般的には、
ウェブに適用したソフトウェアの設計様式のことを指すようになり、
さらに狭義のRESTは、
パラメータを指定して特定のＵＲＬにHTTPでアクセスすると、
ＸＭＬで記述されたメッセージが送られてくるようなシステムおよび呼び出しインターフェース
を
指します。
で、
RESTの制約や原則に則ったウェブサービスが、
ひとまとめに RESTful と形容されたりもしてます。
それでRESTfulなAPIのことを
RESTful API
と
いいますが、
API（Application Programming Interface）の意味がわかれば
これは推測できるとおり、
RESTの制約や原則に則って構築されたウェブシステムの
HTTPでの呼び出しインターフェースのことですね。
どこが簡単か
以上のようにRESTって、定義は非常にややこしくてむずかしいんですけど、
使うには超シンプルで簡単です。
きっと、
制約と原則のおかげでしょう。
RESTは、
システムの状態やセッションに依存せず、
ＵＲＬを指定してパラメータを与えてさえやれば、
常に同じ結果が返されることになってます。
パラメータを与えたら答が返ってくる‥‥
ってことは、
それ自体が極めて明快な関数のように独立して機能するわけですね。
だから気持ちがいい。
RESTは主に以下の4つの原則から成り立っています。
- Addressability：アドレスひとつで指定可能
- Stateless：そのつど完結
- Connectability：ハイパーメディアで参照可能
- Uniform Interface：統一されたインターフェース
うんうん、
うまく説明できませんけど、
だいたいわかりました。
それぞれの意味をかいつまんで説明すると──
- すべての情報がＵＲＬやＵＲＩで表現される一意なアドレスをもっている。
- セッションなどの状態管理を行わず、やりとりされる情報はそれ自体で完結して解釈できる。
- HTMLやXMLといった文書にリンクを含めることで、それだけで他のRESTリソースを参照できる。
- 情報の操作（取得、作成、更新、削除）は、すべてあらかじめ定義され、共有されたHTTPメソッド（GET、POST、PUT、DELETE）を利用する。
かいつまみすぎて伝わりませんね、
すんません。
制約って、
ある面では「縛り」なわけで、
ちょっと聞くとネガティブなイメージですけど、
ウェブの技術はだいたいがややこしすぎてむずかしすぎるだけに、
制約のおかげでルールがシンプルで使いやすくなったと考えられるわけですね。
RESTfulなウェブサービスは、
サービスのＵＲＩにHTTPメソッドでアクセスすることでデータの送受信を行います。
たったそれだけです。
送り方が簡単で、
受け取り方も簡単。
先ほどのイベント参加希望フォームの実例でいいますと、
送信部分のコードは──
$.ajax({
type:'POST',
dataType:'json',
url:'https://zebra.m-tone.red/mtone/rest/request',
data:{
"io":0,
"r":"join_oMTNREST",
"FLNM":FLNM,
"LCTN":LCTN,
"CMPN":CMPN,
"MLAD":MLAD,
"EFEE":EFEE,
"UMSG":UMSG,
},
これだけで、
データ受け取ってエラー判別して、
エラーがなかったらメールを返信してね、
エラーがあったらエラーがあったとわかるように応答してね、
っていう、
一連のお仕事をサーバにさせられるわけです。
受信部分は──
success:function(data) {
gG=JSON.stringify(data["G"]);
gG=gG.replace(/"/g,'');
G=gG.split(';');
vE=document.forms[0].elements
vE['G'].value=gG;
‥‥
要するにこれ、
「G」というたったひとつの変数に、
ほしい情報をぜーんぶブッこんでしまえという意図。
あとは文字列分解すればええやんってことにしとけば、
用途が変わってもワンパターンで対応できますから。
なんて簡単な！
RESTとjson
ここでまたjsonが出てきました。ウェブページをＡＭＰでコーディングするようになってから、
データ構造化ですっかりおなじみのjsonです。
jsonとは、
JavaScript Object Notationの略で、
テキストベースで軽量のデータ交換フォーマット。
Notationは「表記法」なので、
ジャバスクリプトのオブジェクトのノーテーションってことは、
すなわち、
JavaScriptのオブジェクトの表記法を元にしてるってこと。
データ交換フォーマット
ってことは、
なにかしらデータの受渡しに使われるもんだってこともわかりますね。
XMLなどと同様、
テキストベースのデータフォーマットなんですが、
XMLとくらべると簡潔に構造化されたデータを記述することができるため、
書きやすく、
人間が理解しやすいデータフォーマットです。
名前のとおり、
JavaScriptと関係あります。
たとえば
JSON.parse()メソッドは
JSON文字列を解析してJavaScriptのオブジェクトに変換します。
JSON.stringify()メソッドは
JavaScriptの値をJSON文字列に変換します。
そんなふうにJavaScriptと親和性が高いので、
Ajaxでのデータ交換フォーマットとして広く利用されるようになりました。
RESTという概念はずいぶん古くから存在したのに、
いまになって注目を浴びているのは、
ばらばらなシステムで増え続けるウェブサイトや、
ばらばらなインターフェイスで増え続けるマルチデバイスに、
効率よくコンテンツを配信する必要性が高まってきているからです。
あっちのクラウドからこっちのクラウドへ、
中味は別々に自分勝手に動いているけれど、
データのやりとりはシンプルにできないといけない。
だからデータ交換フォーマットが肝心なのです。
と、
わかったような書き方をしてみたものの、
オブジェクト
っ
ていうものの説明がなんせめんどくさくって、
プログラマが１００人いても、
そのうち９９人は意味わからんままやってるはずなので、
jsonの意味もまた理解できるはずがないと思うわけなんですが‥‥
オブジェクト
とは、
データとそれに対する処理をひとまとめにしたモノ
です。
変数と関数をひとかたまりにしたモノ
と
言い換えても同じことです。
なんか、
まとめられてるモノな感じ
は
少なくとも伝わりますね？
{
type:'POST',
dataType:'json',
url:'https://zebra.m-tone.red/mtone/rest/request',
data:{
"io":0,
"r":"join_oMTNREST",
"FLNM":FLNM,
：
：
}
}
のように記述される
｛ ‥‥ ｝の部分。
このカモメ括弧の中に、
いろんなものがまとめられて入ってるわけですが、
そのまとまったもの全体がオブジェクトです。
厳密にいうとまちがっているかもしれなくっても、
そんなふうに覚えておいたらいいですよって話です。
次は何をつくろかな
覚えたてのころは、あれこれいろいろ試してみたいもんです。
＞いまはまだ紙で受けつけている店頭での会員登録を、
＞タブレットでできないか
という相談を受けているので、
それをRESTでやろうかと思いつきました。
会員登録って、
名前やら電話番号やら住所やら、
１０個にも満たない項目に情報をセットしてサーバに送信するだけ。
めちゃめちゃ定型的。
重複チェック登録や、
郵便番号からの住所変換など、
ただの問い合わせフォームよりはちょっとだけ複雑ですが、
ページ遷移せいぜい２回くらい。
もってこいですやん。
静的なHTMLページに、
簡単に組み込めるっていうのが気楽でいい。
サーバにアクセスするのは、
JavaScriptが動く一瞬のことで、
それ以外の操作中はライセンス消費もありません。
（Cachéの場合はＣＳＰっていうしくみを使いますが、
これだとページを開いているあいだじゅうライセンスを食います。）
ええことずくめなRESTですけど、
ま、
聞くところによると、
RESTにはRESTのマニアックな支持者がいて、
＞○○○でなければRESTではない
みたいに叱られたりするらしい。
わーお！
それ、
コワいやんけ。
制約や原則の集まりがRESTなわけですから、
その制約や原則からはみ出したら確かにRESTとは呼べませんもんね。
な、の、で、
わたしがこれから開発するウェブサービスは、
RESTとはなんの関係もないってことにしといてください。
すんませんがそういうオチでよろしく。