質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

91.35%

  • JavaScript

    11209questions

    JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

  • jQuery

    4890questions

    jQueryは、JavaScriptライブラリのひとつです。 簡単な記述で、JavaScriptコードを実行できるように設計されています。 2006年1月に、ジョン・レシグが発表しました。 jQueryは独特の記述法を用いており、機能のほとんどは「$関数」や「jQueryオブジェクト」のメソッドとして定義されています。

  • Spring

    485questions

    Spring Framework は、Javaプラットフォーム向けのオープンソースアプリケーションフレームワークです。 Java Platform上に、 Web ベースのアプリケーションを設計するための拡張機能が数多く用意されています。

  • Spring Boot

    244questions

    Spring Bootは、Javaのフレームワークの一つ。Springプロジェクトが提供する様々なフレームワークを統合した、アプリケーションを高速で開発するために設計されたフレームワークです。

フロントとバックエンドでの入力チェックの同期について

解決済

回答 7

投稿 2017/11/24 17:12 ・編集 2017/11/24 17:13

  • 評価
  • クリップ 5
  • VIEW 1,352

LokiTick

score 12

前提・実現したいこと

昨今UX向上の為リアルタイムで入力チェックをフロント側で行い、POSTされたデータはサーバーで入力チェックする二重チェックをするのが一般的だとおもわれます。、
このチェックのルールの同期(フロントとバックでのチェックルールの統一)の際、有用な方法はなにかありますでしょうか。

質問が漠然としているのでお答えするのが難しいと思いますがよろしくお願いします。
また、業界では一般的にどのようなほうほうを取っているのか知りたいです。

試したこと

validatorAPIを用意して、フロント側ではAjaxで叩く、サーバ側ではもちろんそのまま使う → 同じVaridatorを使うことになるが、結局サーバに接続してるのでUX向上につながらない?

頑張って同じルールになるように両方で同じ処理を書く → 同じ処理を書くのが大変だし、なにより修正のとき大変。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 7

checkベストアンサー

+4

 サーバサイドとクライアントサイド

昔はサーバサイドでバリデーションを行う方法しか存在しませんでした。
クライアントサイドでのバリデーションが注目されたのは、「クライアントサイドによるバリデーション」がサーバに送信されるまでバリデーション出来ないという「サーバサイドによるバリデーション」の欠点を克服できるものだったからです。
しかし、「クライアントサイドによるバリデーション」はHTML/JavaScriptを書き換えればバリデーションなしで送信出来てしまう不完全性の問題があります。
現在はサーバサイドで完全なバリデーションを行い、クライアントサイドでも同様のバリデーションを行うことで、ユーザのバリデーションにかけるまでのタイムラグを出来るだけ小さくしているのが実情です。
クライアントサイドによるバリデーションはサーバサイドのそれと同じである方が勿論好ましいですが、必ずしも完全に一致する必要はありません。
その代わり、サーバサイドによるバリデーションが完全性を保証する必要はあります。

 サーバ/クライアントサイドのバリデーションを同期する

このチェックのルールの同期(フロントとバックでのチェックルールの統一)の際、有用な方法はなにかありますでしょうか。

「全く同じバリデーションになるように双方のアルゴリズムを組む」以外に方法はないと思います。
クライアントサイドからサーバサイドに逐一リクエストしてサーバサイドで判定することで完全に一致させつつ、クライアントサイドのコーディング量を少なくすることが可能ですが、それでは「クライアントサイドのメリット(HTTPリクエストするタイムラグがない)」を相殺します。

(2017/11/24 22:49追記)
サーバにnode.jsを採用すれば、JavaScriptコードを部分的に流用出来るかも知れません。

Re: LokiTick さん

投稿 2017/11/24 22:44

編集 2017/11/24 22:49

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/25 11:51

    バリデーションの歴史についても勉強になります。
    やはりルールの統一は同じように動くよう組むのが現実的なようですね。
    それと、サーバ側で用意したAPIを利用して逐一監視する方法はタイムラグがないことを相殺するので、なんのために実装するのかの目的の整理も必要そうですね。
    ありがとうございました。

    キャンセル

+4

フロントエンドのUIで入力チェックは所詮pattern属性くらいが限界ですよね
バリデート処理も必ずしも同じ結果を期待しないと思うのであくまでも別物として
設定すればよいのでは?
UIのチェックはユーザーの負担になるくらいならなくてもいいくらいだと思います。

投稿 2017/11/24 17:57

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/24 18:17

    状況が許せば、patternファイルをセッションで共有して
    受け取り側はfilter_input()のFILTER_VALIDATE_REGEXPフィルタで
    おなじ条件を設定することは可能かもしれませんが
    必ずしも正規表現がバリデートに最適かといわれると疑問が残ります

    キャンセル

  • 2017/11/25 11:41

    patternファイルを引き回すコストを考えるとそこまでして揃える必要はないのかなと思いますね。
    やはり、割り切って別物として設定するのが良さそうですね。ありがとうございました。

    キャンセル

+3

クライアントサイドのバリデーションは、「requiredmaxlengthのように、属性1つでかけられる程度に限ってしまう」というのも1案ではあります。

あと、サーバサイドもNode.jsの場合、「同じコードをクライアントに送って、バリデーションを共用する」というアプローチも見たことがあります。

投稿 2017/11/24 18:05

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/25 11:46

    やはり、ある程度の割り切りは必要ということですね、Node.jsについては知見がないので的はずれかもしれませんが、サーバ側で作ったスクリプトコードをクライアントで使うということでしょうか。

    キャンセル

  • 2017/11/25 12:27

    そうですね、Node.jsはJavaScriptで動くサーバなので、バリデーション用JavaScriptを共有するのも、他言語と比べたらかなりハードルが低いです。

    キャンセル

  • 2017/11/27 09:26

    なるほど、勉強になりました。

    キャンセル

+3

頑張って同じルールになるように両方で同じ処理を書く
 → 同じ処理を書くのが大変だし、なにより修正のとき大変。

同じAPIをクラサバ両方で呼べば一番簡単ですが、サーバ接続したくない場合、
トランスパイラ(JavaならHaxe)で変換する方法があるかも、と言ってみるテスト。

もちろん、入力チェックのためだけだと、学習コストが高く付くでしょうが、
他の何かでも使って、ついでにやるなら、試す価値くらいはあるかもしれません。

投稿 2017/11/24 22:45

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/27 09:25

    Haxeですか初耳です。
    いろいろな言語への変換ができる結構新しい言語なのですね。
    おっしゃる通り入力チェックのためだけに学ぶのはかなり学習コストが高く付きそうです。
    こういった方法もあるということで大変ためになりました。

    キャンセル

+2

案だけ。

ClientValidator - チェック処理実装はJavascript
ServersideValidator - ClientValidatorをjavax.scriptパッケージ等を使用して呼び出す。

という形にすると、チェック実装はjavascirptだけで済む。

メンテナンス性だけを考えればこういう案もある、という程度で。

投稿 2017/11/24 17:58

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/25 11:44

    サーバ側で、rhinoを使ってスクリプトを利用するということですね、たしかにメンテナンス性は高そうですね。ありがとうございました。

    キャンセル

0

自分はクライアントサイドとサーバーサイドの入力検証の一元化については
HTML5の属性値による入力検証に落とし込めるものについてはその形で
できないものについてはAjaxでというような感じにしてます

そのためにまず設定と処理を分けています

設定された入力検証がpattern,require,max,minならHTML出力時に属性値として出力し
callbackであればajaxで検証するようにする、というような感じです
(もちろんHTMLの属性値として出力した入力検証についても
受信時に同じ設定を利用して改めてサーバーサイドでも検証します)

入力検証の中には商品とオプションの組み合わせで入力値の制限が変わるというような
およそクライアントサイドに全ての情報を落とし込むのは現実的でない、望ましくないが
ユーザーにはリアルタイムに入力値制限をしてあげたいものがあるので
Ajaxによる入力検証の仕組みは軸として持っておくべきと思ってます

投稿 2017/11/28 11:11

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

クライアントサイドはJavaScriptで書き、サーバサイドは別の言語で書くとします。
しかし、Validation規則は共通のDSLで書く、ということで良いのではないですか。
そのDSLを両サイドの言語で実行時に解釈するなり、トランスパイル/コンパイルのタイミングでそれぞれの言語に翻訳すれば良いですね。

投稿 2017/11/30 06:58

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

ただいまの回答率

91.35%

関連した質問

同じタグがついた質問を見る

  • JavaScript

    11209questions

    JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

  • jQuery

    4890questions

    jQueryは、JavaScriptライブラリのひとつです。 簡単な記述で、JavaScriptコードを実行できるように設計されています。 2006年1月に、ジョン・レシグが発表しました。 jQueryは独特の記述法を用いており、機能のほとんどは「$関数」や「jQueryオブジェクト」のメソッドとして定義されています。

  • Spring

    485questions

    Spring Framework は、Javaプラットフォーム向けのオープンソースアプリケーションフレームワークです。 Java Platform上に、 Web ベースのアプリケーションを設計するための拡張機能が数多く用意されています。

  • Spring Boot

    244questions

    Spring Bootは、Javaのフレームワークの一つ。Springプロジェクトが提供する様々なフレームワークを統合した、アプリケーションを高速で開発するために設計されたフレームワークです。