今時のWEBサイトPOST事情

その昔のインターネットホームページは、CGI + HTMLが主流でしたが、ここ最近では、HTML5+CSS3に始まり、Ajax(javascript)からサーバーサイドJavascriptなど、複雑になる要素が満載です。 便利なライブラリやフレームワークも氾濫していて、最新の技術を使いたいエンジニアはこうした技術（主にライブラリ）を多用して構築するWEBサイト（サービス）の中身をレビューしてみると、とんでもない複雑極まりないシステムが出来上がっていることがあります。 基本的にそうした複雑WEBサイトは、新しくもなく、機能追加や修正などの作業が極めて大きな作業になることがあり、非常に非効率なシステムになっており、残念なシステムと結論付けてしまいます。 そうです、システムはシンプルであるべきなんですね。

いろいろなPOST方法

今回考えたいのは、僕も個人的にシステムを構築していて、自分で複数のPOST方法を使っていることに気が付いたので、どういう場面でどの方式を使うのがいいかをまとめるために、この記事を書いています。

HTML+CGIのsubmit方式（レガシー）

HTMLにformタグを書き、submitする事で、サーバーにPOSTパケットが飛びます。 それをCGIで処理するという最もシンプルなWEB-POST方式ですが、TLS暗号化技術も日々進化しており、その昔の掲示板を思い出す手法です。 この手法のメリットは何と言ってもシンプルである事でしょう。 デメリットはというと、POSTすることにより、現在みているページからREQUESTされるために、ページの読み込みが発生します。 ページが切り替わってしまうタイムラグも含めて、操作感が少し失われてしまうという可能性があります。

Ajax-POST方式

Javascriptで当たり前のように使われているAjaxは、「非同期」処理を行いページを再ロードせずに、CGIとコミュニケーションが取れるというメリットがあり、FORMデータの送信も行うことができます。 HTML+CGI方式のデメリットを克服できるため、インタラクティブなUIに重きを置くWEBサービスなどは、この手法を使っている事が多いでしょう。 また、jQueryプラグインが大流行して、「Ajax=jQuery」と認識している若手プログラマーも少なくなく、プラグイン依存しているエンジニアは、色々なトラブルを引き寄せてしまうため、ネイティブコードでの技術習得をちゃんとする事をお勧めします。

GET送信

POST送信の記事ですが、もっとも手頃なGET方式を忘れてはいけません。 WEBサイトでデータをサーバーに送るためには、データ暗号化を考えなければGET方式がもっとも手軽に行えます。 GET方式は、submit方式もajax方式もどちらも使えますが、この方式のメリットは、aリンクで送信できてしまう事でしょう。 わざわざpostするために、formタグを作って、ボタン処理でsubmit送信するとか、ajax処理をコーディングするまでもなく、Aタグひとつで手軽にデータを送る事が可能です。 しかし、手軽が故に、きちんと受け取り処理などを行わないといけなくて、URLやURIをリロードするとデータが複数回送信されるような自体も不具合の原因になる可能性があります。

NodejsのSocketIOによるemit送信

最も今時のやり方なのが、SocketIOによるポーリングでのデータ送信を行うと、タイムログがほぼなく、常にサーバーにデータ送信（受信）が可能になります。 チャットシステムなどで使われる技術ですが、一昔前のCGIだけでやっていたチャットが懐かしく感じます。 ページを再ロードすることもなく、相手が書き込みをしたらリアルタイムにそのページを見ている全ての人の表示が更新される仕組みは、ゲームなどでも利用されており、ストレスフルなWEBシステム構築では不可欠と言ってもいいかもしれません。 全てこの仕組みにすればいいかというと、そうでもなく、この仕組みの最大のデメリットは、サーバー負荷が極めて高くなるという点です。 そもそも通信の技術的な仕組みをちゃんと知っている人であれば、簡単に想像できると思いますが、ポーリングというのは、送信と受信とイベントを便利に操作できるという風に見えますが、データ通信技術というのは基本的に「送信」しか存在しません。 ポーリングは、毎秒クラスのセッション処理を随時行って、変化が起きたタイミングをイベントとして取得しているように見せているだけで、常にパケット送信が行われています。 その際に基本送信だけで行っている中にresponce値を受け取り受信という処理に見せかけているだけなんですね。 そのため、サーバーではものすごく忙しい処理をこなさなければいけなくなり、ゲーム会社がサーバー管理に力を入れているのはこのためなんですね。

HTML5時代のPOST方法

主に上記のいくつかのパターンで、いったいどういう送信方法が最適なのかというと、どれか一つという答えはなさそうです。 全ての方式を送信する場面によって使い分けるのが一番最適であると、考えられます。 では、それぞれの使うケースはどういう場面になるか考えてみましょう。

HTML+CGIのsubmit方式（レガシー）

データ登録や管理画面系の確実にデータ送信したという実感を持ちたい場合のUIには、この方式を使うのがいいでしょう。 ECサイトの決済機能で、送信完了をきちんとレスポンスした状態確認ができる必要がある場合に、一番スムーズに使われるでしょう。

Ajax-POST方式

WEBページをリロードさせないようにデータ送信を行いたい場合や、サーバーからインタラクティブにデータ取得をしたい場合に使える方式ですが、グラフを表示するようなページで、データを切り替え取得する場合など使う事で効果的になるでしょう。 また、javascriptを使った様々な機能拡張できるツール作成をする際などは非常に便利に使えるため、この手法が便利に使えるエンジニアが最近のサービス構築には重宝されるようです。

GET送信

当たり前ですが、URIの基本として、クエリ値（？key=value）とハッシュ値（#ハッシュID）によりデータ送信する事ができますが、基本的には、データがついた状態のURLを再ロードしても問題ない場合に使用しましょう。 WEBサイトのメニューなどで使われる事が一般的なようです。 formデータをクエリで送信するのは、セキュリティ的にも非常に危険なので、こうした使い方は行うべきではありません。

NodejsのSocketIOによるemit送信

基本的には、チャットなどのポーリングが必要なサイトで使う事が多いようですが、ajaxとポーリングを同じ感覚で使っているエンジニアをたまに見かけますが、この技術やはりチャット機能が最適な使い方でしょう。

ケースバイケースでセキュアなデータ活用

基本的なデータはどの方式を使っても同じなわけですが、利用するユーザーの感覚は大きく変わります。 サーバーからのレスポンスを待たないといけないような場合は、ネットワーク遅延の場合にイライラしてしまいますが、一旦送信するとバックグラウンドで送信処理をしてくれていて、失敗したらその旨報告がくるという仕組みにするだけで、ユーザーは無駄な時間を費やさずに、ページ内での他の操作を進めていく事が可能になります。 仮に送信失敗した場合は、ダイアログが出て再送信作業をする方が、待った挙句に失敗画面を見た場合と比べてショック度合いがかなり違うという心理的要素をきちんとUI/UXとして検討しなければいけないというワケです。 ただし、一番考えたいところは、冒頭で愚痴ったように、メンテナンスコストを考えていないと、そもそもエンジニア自身が使いづらいシステムになりかねないという事です。 コーディング技術にも影響してくるかもしれませんが、システムはシンプルであるべきという意見には非常に賛成できますね。