Webアプリケーション-Wikipedia

一 ウェブアプリケーション （また オンラインアプリケーション 、 WebApplikation または短い Web-App ）は、クライアントサーバーモデルに従ってアプリケーションプログラムです。クラシックデスクトップアプリケーションとは異なり、Webアプリケーションはユーザーのコンピューターにローカルにインストールされていません。データ処理は、遠くのWebサーバーで部分的に行われます。データ処理の結果は、ユーザーのローカルクライアントコンピューター（シンクライアント）に転送されます。通常、WebアプリケーションはWebブラウザを介して使用されます。 Webサーバーでは、これは通常、HTTPプロトコルを介して通信します。

デスクトップアプリケーションとは異なり、Webアプリケーションではユーザーのコンピューター上の特別なオペレーティングシステムは必要ありません。ただし、一部のWebアプリには、現在のWebブラウザーまたはJavaScriptなどの特別なランタイム環境が必要です。

可能であれば、実行ロジックの一部はサーバーでは不可能ですが、特に予備検証のために、クライアントコンピューターでは既に不可能です。入力エラーは既にローカルで認識されています。これは、遠くのサーバーからの返信を待つことなく、ユーザーへのフィードバックがすぐに行われることを意味します。
AJAXテクノロジーを使用して、Webクライアントのコンテンツのサブエリアのみが更新され、再度Webサイトにアクセスすることなく更新されます。
このような分布は、FATクライアントアーキテクチャまで拡張できます（単一ページのWebアプリケーションを参照）。

Internet -Compatibleのモバイルスマートフォンとタブレットコンピューターの拡散により、略語の使用は広がりました Web-App ますます。

一般的な機能 [ 編集 | ソーステキストを編集します ]

zでWebアプリケーションを開始します。 B.ブラウザにWebサーバーのURLを入力すると、お問い合わせ（HTTPリクエスト）を送信します。 Webサーバーはリクエストを受け入れ、Webアプリケーションに渡します。これにより、WebサイトのHTMLソースコードが作成またはロードされます。これは、Webサーバーからユーザーのブラウザ（HTTP応答）に送信されます。このWebサイトは、Webアプリケーションのグラフィカルユーザーインターフェイスです。 Webアプリケーションのレイヤーアーキテクチャを見ると、Webブラウザのプレゼンテーションレイヤーが実行されます（Thin Client）。ロジックレイヤーとデータ姿勢の一部は、サーバー上で実行されます。

このWebサイトのハイパーリンクをクリックするか、フォームに記入して送信することにより、Webサーバーに新しいリクエストを開始します。などの詳細情報B.フォーム（http post）、左のパラメーター（http get）、およびWebサーバーに送信され、Webアプリケーションによる入力として処理されたHTTP Cookieのデータで作成されたエントリ。などのインターフェイスについてB. Common GatewayインターフェイスまたはFastCGIは、Webサーバー内のWebアプリケーションに統合されています。このようにして、問い合わせはWebアプリケーションに転送され、Webアプリケーションの支出が応答して返されます。 WebアプリケーションによるこのようなHTTP要求の処理は、要求サイクルとも呼ばれます。

Webアプリを使用する場合 セッションデータ （例：Webショップの注文データ）データベースまたはファイルに保存されています。ユーザー関連のデータは、HTTP Cookieによって保存することもできます。サーバーセッション – アクティブユーザーセッション – サーバーリソース消費。深刻なセッション情報は、Webアプリケーションの水平スケーリングも複雑にします。したがって、シングルページWebアプリケーションや残りのパラダイムなどのWebアプリケーションの代替アーキテクチャアプローチは、サーバー側とクライアント側の実行を組み合わせています。

WebアプリケーションはかつてWebサイトのHTMLソースコードのみを作成しましたが、それ以来、画像、アニメーション、ビデオ、オーディオファイル、PDFドキュメントが生成されています。

モバイルWebアプリの仕組み [ 編集 | ソーステキストを編集します ]

Webアプリケーションには、任意のエンドデバイスで操作できるという利点があります。エンドデバイスには、必要なWeb標準（HTML5やJavaScriptなど）をサポートするWebブラウザが必要です。モバイルアプリケーションの分野には、アプリケーション開発のためのプラットフォーム固有のインターフェイスがあります。ターゲットプラットフォームごとに個別の実装を実装する必要があります。このような実装は、ネイティブアプリと呼ばれます。ただし、Webアプリケーションはすべてのプラットフォームで実行できます。それらはモバイルWebアプリと呼ばれます。

通常、WebアプリケーションはWebサーバーで実行されますが、1つ以上のアプリケーションサーバーに外注することもできます。これは、1つ以上のWebサーバーによるユーザー問い合わせで動作します。 2つのアーキテクチャを区別できます。

スタンドアロン

Webアプリケーションは、独立したバイナリプログラムまたは独立したバイナリプログラムによって解釈されるスクリプトであり、各リクエストに対して再起動されます。このようなアプリケーションは、主にCGIプログラムと呼ばれます。

統合

Webアプリケーションは、Webサーバーの一部またはWebサーバーによって解釈されるスクリプトです。リクエストサイクルごとにプログラムを開始する必要はなくなりました。例：PHP、Perl、Python、Ruby（Webサーバーの対応するモジュールで解釈）、Javaサーブレット、Javaserverページ、またはASP.NET。

Webアプリケーションは、従来、サーバー上で強化されています。また、Webアプリケーションのよりクライアントが多い実行を提供するアプローチもあります。 Webクライアントは、サーバー側のリソースを緩和するためにますます独立したユニットになります ^[初め] 。これらのアプローチは、特にB2CアプリケーションなどですB. FacebookまたはGmail-そのようなプロジェクトで多数のユーザーが期待できるため、関連性があります。クライアントサーバー通信をWebクライアントとのやり取りのためにトリガーする必要がないため、ユーザーエクスペリエンスも改善できます。これにより、Webアプリケーションの応答時間が遅くなります。

豊富なインターネットアプリケーション

定義上、リッチインターネットアプリケーション（RIA）には、クライアントのより高いレベルのプログラムロジックが必要になります。たとえば、クライアントのサーバーではなく計算を実行するためです。厳密に言えば、Webプロジェクトは、JavaScript（AJAXを含む）、Javaアプレット、Flashアニメーション、ActiveXプラグインなどを使用するWebアプリケーションで使用されます。

シングルページWebアプリケーション

単一ページのWebアプリケーションは、RIAアプローチとWebサービスを組み合わせています。 Webアプリケーションの完全なプレゼンテーションレイヤーがクライアント側に実装されています。さらに、サーバー側の専門的な概念とデータ姿勢のさらなる機能は、クライアント上のWebアプリケーションのオフライン操作の中間メモリとして実行できます。 ^[初め] したがって、これはWebアプリケーション用の太ったクライアントアーキテクチャです。このアプローチでは、Webサーバーは、JavaScript、CSS、およびImageファイルの配布と、Webサービスを介したユーザーデータの提供のみを担当します（例：Rest-API経由）。このようなアプローチは、しばしばいわゆるハイブリッドアプリを作成します。モバイルエンドデバイスのソフトウェアコンポーネントにアクセスし、同時に異なるプラットフォームを操作することにより、ネイティブアプリとWebアプリの利点を組み合わせます。

ウェブサービス

Webサービスを使用すると、Webサーバーは、主に直接表示用に意図されていない構造化された形式で情報を提供します。 XHTMLの導入以来XMLに戻ってきたため、XMLの使用だけではWebアプリケーションを区切るのに十分ではありません。 Webサービスを使用すると、XMLデータは、クライアントのプログラムでさらに処理することを目的としています。ユーザーとのやり取りでさえ、必須の要件ではありません。 JSON形式は、データ形式としても使用されます。これは、XML構造の解析がもはや必要ではないため、JavaScriptベースのWebクライアントによる消費の利点を提供します。

利点 [ 編集 | ソーステキストを編集します ]

Webアプリケーションには、ユーザーのコンピューター上のWebブラウザのみが必要です。これは通常既に利用可能です。従来のデスクトップアプリケーションとは対照的に、Flashなどのブラウザプラグインを控える場合、ソフトウェアのさらなるインストールは必要ありません。これは、多くのブラウザーがサポートされている場合、Webアプリケーションが高度なプラットフォームの独立性を達成することを意味します。

Webアプリケーションのロジックを変更する必要がある場合、Changeは中央ポイント（Webサーバー）でのみ必要です。これは、メンテナンスコストに有利な影響を及ぼします。これも安全性の利点をもたらします。セキュリティギャップはすぐに改善できます。また、Webアプリケーションが完全に侵害されていても、ユーザーシステムで他のプログラムはリスクがありません。

短所 [ 編集 | ソーステキストを編集します ]

Webサーバーへの接続は、Webアプリケーションを使用する必要があります。接続のデータレートは、Webアプリケーションの要件についても設計する必要があります。これは、次のような多くの運用シナリオのWebアプリケーションを締めくくります。 B.定義上、モバイルオフライン使用。 Webアプリケーションは、セッションIDを介して登録ユーザーを識別します。これにより、セキュリティの問題が発生する可能性があります（以下を参照）。

理想的には、WebアプリケーションはすべてのWebブラウザーで適切に動作する必要があります。ただし、実際には、HTMLブラウザは既存の標準（W3C）にもかかわらず解釈されるため、これは当然のことではありません。異なるブラウザ間の表現のわずかな逸脱は通常無関係であり、JavaScriptの解釈には違いがあります。そのため、ブラウザスイッチを使用する必要があることがよくあります。さらに、上記の要求サイクルにより、非同期処理のみが可能です。これは、Webアプリケーションとして多くのアプリケーション領域（ビデオの処理など）を除外します。さらに、ユーザーインタラクションオプションの実装とクライアントのハードウェアリソースへのアクセスの可能性ははるかに限られています。

Webアプリケーションの場合、ユーザー入力を受信する必要があります。今日使用されているHTMLフォームは、1993年11月8日の「HTML+」のドラフトに初めて含まれています。 ^[2] しかし、Tim Berners-Leeの最初のHTMLバージョンは、「iSindex」日でWebサーバーにパラメーターを送信する方法をすでに提供しています。パラメーターは、HTTP GETメソッドの先駆者であるURLに取り付けられました。
これを使用した最初の大型システムは、おそらくスタンフォード大学のデータベースである「Spires-hep」のWebインターフェイスでした。 ^[3] 今日のすべてのWebアプリケーションのこの祖先は、1991年にオンラインになりました。

HTMLフォームの広範なサポートを実装した最初のWebブラウザは、1993年12月のNCSA Mosaic 2.0でした。当時、最大の分布を持つブラウザ。フォームデータを受信する最初のサーバー側インターフェイスは「htbin」でした。これは、W3C HTTPサーバーのバージョン2.13の一部として1993年11月4日に公開されました。すでに1994年2月11日に、現在も使用されているCGIインターフェイスは、リリース2.15ベータ版に続きました。 CGIは、使用されるプログラミング言語とは無関係です。 CまたはPERLは、最初のWebアプリケーションに使用されました。 Perlは、弦チェーンの処理のための強力な機能のために自らを提供しました。

一般大衆によって認識された最初のWebアプリケーションも、スタンフォード大学で作成されました。 2人の学生は、個人のブックマーク管理からYahoo Webサイトを開発しました。プログラミング言語として、彼らはPerlを使用しました。

次の年には、パフォーマンスを向上させるCGIインターフェイスのさらなる開発がありました。 1997年春、Sun Microsystemsはサーブレットテクノロジーをリリースしました。サーブレットは、CGIプログラムに非常に似たJavaプログラムです。主な違いは、HTTP要求が独自のプロセスでは処理されず、独自のスレッドのみが処理されることです。これにより、パフォーマンスが大きくなりました。

ただし、プログラムコードにしっかりと保存されているHTMLコードのWebサイトをまとめる手順ですが、大きな問題はプログラムが面倒であり、ロジックとコンテンツを分離することを許可しませんでした。この問題は、いくつかの側面から同様の方法で解決されました。動的に生成されたエディションのプログラムコードは、それ以外の場合は静的なHTMLに組み込まれています。このアプローチの後には、1997年頃にPERLプロジェクトから出現した言語PHP、サーブレットに基づくJavaServerページ、およびMicrosoftのActive Serverページ（ASP）が出現しました。

ミレニアムのターン中の大きなインターネットブームの時代に、Webアプリケーションは大きな後押しを経験しました。証券取引所で称賛されているニューエコノミー企業の多くは、Webアプリケーションにビジネスモデルを設定しました。誇張された期待は、2001年にいわゆるドットコムバブルのバーストにつながりました。ただし、この間、ようなWebアプリケーションB. eBay、Yahoo、Googleは、今日のWebライフの自然な部分になっています。

Ajaxが移動して以来、クライアント側のリソースがアプリケーションの操作にますます含まれています。より多くのインタラクティブ性を望んでいるため、AJAXを介してより多くのコンテンツを動的に充電し、現在のビューの大聖堂構造を動的に拡張する必要がありました。これに必要な制御ロジックは、JavaScriptで実装され、Webブラウザーで実行されます。新しいページコンテンツを提示するためには、サイドの古典的な変化は絶対に必要ではありません。シングルページWebアプリケーションのパラダイムは、Webアプリケーションのプレゼンテーションレイヤーのクライアント側の実行のみに基づいています。

Webエンジニアリングは、ソフトウェアエンジニアリングの方法をWebアプリケーションの開発に転送する学術分野として作成されています。

Webアプリを作成するためのさまざまなフレームワークがあります。

古典的なWebデザイナーとモバイルWebアプリ開発者のコ​​ンピテンシーは、モバイルインターネットへの焦点がコンテキストであり、コンテンツでは（のみ）コンテキストであるという点で大きく異なります。特にユーザーインターフェイスは、モバイルWebアプリの開発における重要な要素です。

Webアプリケーションのセキュリティは、ここでそれを扱うには幅が広すぎます。そのため、このセクションは、Webアプリケーションに関連する一般的な攻撃オプションの説明に限定されています。 Webアプリケーションに対する攻撃は、実装中のセキュリティギャップを避けたり、上流のWebアプリケーションファイアウォールを使用して困難にしたり、かわしたりすることで防止できます。

以下の攻撃は、Webアプリケーション自体に向けられていませんが、環境でしばしば見つかります。

• クライアントサーバーの通信中に、中間の攻撃と積極的に
• サービスの拒否 – これ以上の問い合わせを受け入れることができないようにWebサーバーに過負荷
• 偽の電子メールやウェブサイトの外観に関するフィッシングスチール顧客データ

いくつかの例は、カテゴリのWebアプリケーションにあります。

1. ↑ ^{a b} Webアプリケーションの変更（SPA）の説明
2. ↑ HTML+ドキュメント形式のレビュー
3. ↑ slac.stanford.edu