JavaScriptは機能するためには絶対に必要なフォームがあり、検証はクライアント側で行われます。検証もサーバー側で実行されますが、サーバー側の検証が失敗した場合にエラーを表示するには非常に手間がかかります。JavaScriptが必要な場合にサーバー側の検証が失敗した場合にエラーを表示しないでください。
ユーザーはJavaScriptを使用できないため、HTTPエラーで失敗するのは問題ありませんか？サーバー側の検証に失敗する唯一の方法は、悪意のあるユーザーかJavaScriptを使用できない場合で、いずれの場合でもフォームを使用しない場合でした。
ありがとうございました
これは、特定の種類のエラーについてはを除いて、これは問題ありません。と言います。
いくつかの検証エラーは悪意のある結果ではありませんが、フォームが実際に処理された時以外には確認できず、発見できません。これは予約されている必要があるリソースが不足している（「このユーザー名は既に使用されています」）か、サーバー側で回復可能なエラーがあるためです（「アップストリームのクレジットカードプロセッサーが応答しません。後で "）。このようなエラーの場合、何らかのエラーメッセージがユーザーに伝えられるはずです。このような種類のエラーを送信することは不可能な設計を想像するのは難しいです。非常に少なくとも、あなたがこれを行うことができます：
しかし、最も重要なことは、サーバー側の検証を行い、クライアントを信頼しないことです。あなたはすでにこれをやっているので、それ以上のことをしたいのであれば、それは最善のユーザーエクスペリエンスを目指すためのものです。時には、それは不必要な努力を必要とし、それは大丈夫です。
私は個人的には大丈夫だと思います。
特に、サイトを使用する前のステップでもJavascriptを使用しないと全く機能しない場合は、Javascriptなしで問題のページに進むことはできませんでした.Javascriptを使わないと無駄な努力です。たとえば、.Netウェブフォームでは、ログインするにはJavascriptが必要です。そのため、サイトのセキュリティ保護された領域内のどのページでも、Javascriptが利用可能であると想定することができます。
私は他の人が考えるものが好きです。
httpリクエストが失敗する唯一の使用例が、誰かがブラウザをバイパスしたときだけであれば、httpリクエストに失敗するだけで問題はないようです。予想されるユーザーシナリオには影響しませんが、サーバー側の検証でサーバー側の整合性を保護しています。それ以上の仕事をしても意味がありません。私にはうまく見えます。
サーバーからエラーUIを表示するために多くの作業を行う価値があるのは、悪いデータがサーバーに届く実際の正当なユーザーシナリオがある場合です。しかし、正当なシナリオがそこに行くことはありそうもないとは思えないので、余分な仕事をする理由はありません。
クライアント側の検証とサーバー側の検証が同等であることが確かである限り、問題ありません。このノートでは、クライアント側の検証コードとサーバー側の検証コードを同期させておくことが面倒です（特に、それらが異なる言語で書かれている場合は、node.jsやGWtを使用していない場合は常にそうです） ）。誰かがそれが素晴らしいだろう何か解決策がある場合。
ただし、サーバー側（データベースの一意性制約など）でのみ実行できる特定の検証がある場合は、クライアント側の操作が失敗したことをユーザーに示すことが重要です。それはアプリケーション自体にも依存します。