回答:
ポストバックは、ページ上のデータ(ページ全体)がクライアントからサーバーにポストされるときに発生します。つまり、データがサーバーにポストバックされ、ページが更新(再描画)されます... ' サーバーに全ページ(asp.net)のデータを送信 'として。
一方、コールバックも特別な種類のポストバックですが、これはサーバーへの簡単なラウンドトリップであり、少量のデータ(通常)を取得するため、ポストバックとは異なり、ページは更新されません。 ...「サーバーを呼び出し、データを受信する」と考えてください。
Asp.Netでは、ポストバックとは異なり、コールバックが呼び出されてもViewStateは更新されません。
ASP.Netは、ページ全体を囲むので、ページ全体がASP.Netに掲載されていることを理由はある<form>
とPOSTメソッド、および送信ボタンがページにクリックされたときに、フォームがすべてとサーバに送信されますフォーム内のフィールド...基本的にページ全体。
FireBug(Firefox用)を使用している場合は、実際にでサーバーに対して呼び出されているコールバックを確認できますConsole
。これにより、サーバーに送信されている特定のデータ(Request
)と、サーバーから送信されたデータ(Response
)が表示されます。
以下の画像は、ASP.NETベースのWebサイトにおけるポストバックとコールバックの両方のページライフサイクルを示しています。
(ソース:esri.com)
Dreasの回答に同意しますが、いくつかポイントを追加したいと思います。ポストバックは、Dreasが説明したように、ASP .NETプログラミングによってごく最近導入された用語ですが、コールバックはより一般的で、Web開発が存在する前に使用されていました。実際、私がCでプログラミングを始めたときのコールバックについて最初に耳にしました(おそらくその用語はその前に存在していたのかもしれませんが、わかりません)。それは単に関数へのポインターと関数へのポインター(このAと名付けます)を意味しますAを後で呼び出す別の関数(このBという名前)に渡されます。コールバックも最近Yahoo UI Connection Managerや他のAjaxフレームワークで使用されていますが、この用語は昔のC時代に初めて使用されたと思います。
この議論の多くはASP.NET gobbledygook言語です...
答えはYESです。ポストバックはMicrosoftのASP.NETに固有の「用語」ですが、MicrosoftのようなベンダーはこれらのプロセスのOWNバージョンをそれらの独自の実装にラップしているため、Http / Htmlの世界で実際に何が起こっているのかについて混乱しています。
POSTBACKのバージョンは、基本的には元のサーバーに送り返される従来のHTTP POSTリクエストです。しかし、ASP.NETでは、Webページのごく一部にある従来のフォームコントロールではなく、巨大なFORM HTML要素タグ(POSTメソッド属性を含む)をWebページ全体に貼り付けます。これは、HTTP仕様を使用してページとそのコントロールの「状態」を維持し、従来の非フォームフィールドマークアップであってもページ全体が元の状態に戻るようにするためです。
残念ながら、これは膨大な量の不要なデータをネットワーク経由で送信するため、ページ内のVIEWSTATEとその姉妹のPOSTBACKは、帯域幅の浪費とWebページの状態を実装するずさんな方法として多くの人に見られるようになりました。キャッシュ可能なCSSと一貫したHTMLマークアップを使用して設計されている場合、ほとんどの最新のブラウザーとWebサイトは、ブラウザーのネイティブHTMLキャッシュを使用してページの状態を非常に自然に返すことを示します。つまり、完全なPOSTBACKはしばしば不要です。
コールバックは単なるJavaScriptです。そのちょうどECMASCRIPTサーカスは、ASP.NETストアをだまして、ブラウザーがサーバーからダウンロードする巨大なJavaScriptライブラリでAJAX APIを呼び出し、どのASP.NET開発者が無意識のうちにWebページにパックして、完全なPOSTBACKなしでWebページの変更をトリガーします。AJAX用のASP.NET APIは、クライアント側にあり、ユーザーが何かを変更したり、何かをロールオーバーしたり、ブラウザーで何かをクリックしたりすると、従来のJavaScriptブラウザーDOMイベントをトリガーするブラウザーでトリガーされる、この巨大なJavaScriptをすべて作成します。次に、大量のJSONまたはその他のデータをサーバーに送り返して処理します。次に、ブラウザのメモリ内のJavasciptedライブラリとオブジェクトによって返されて受け入れられ、ユーザーのWebページとマークアップの一部を変更します。
ユーザーやブラウザの約5〜10%でJavaScriptが無効になっているため、このJSONとAJAXはすべてクラッシュし、それらのユーザーのために書き込みが行われます。つまり、コールバックは機能しません。
それが舞台裏で起こっていることです。あなたが私に尋ねれば、それの多くはやり過ぎです。ASP.NETのWebコントロールモデルが過去に批判されたのはそのためです。
ASP.NETを1秒間放棄した場合は、1つのテキストボックスとボタンを使用してHTML Webページに簡単なFORMフィールドを自分で記述し、それを押して、ASP.NETページとまったく同じようにサーバーへの投稿を監視できます。より速く、よりシンプル。それが本当のPOSTBACKです。ブラウザーは自然にサーバーに必要なPOST HTTPヘッダーを送信しますが、ページの残りの部分にHTMLをキャッシュするため、それ自体で高速にレンダリングされます。
コールバックの場合は、単純なJavascript / ECMAScriptコードを同じHTMLページに追加するだけで、ユーザーがテキストまたはボタンの上にマウスを移動したり、フォームフィールドをクリックしたり、変更したりすると、WebページはPOSTせず、背後でJavascriptで何かをサーバーに送信します。独自のJavaScript、JSON、またはライブラリを介してそれを処理する方法は、別の取引です。しかし、それは魔法ではありません。JavasciptまたはJavaScriptが無効になっていない人は、コールバックのないページを設計し、フォームフィールドコントロールまたはハイパーリンクがクリックされたときに返されるすべての変更をキャッシュする必要があります。最近のほとんどのユーザーエージェントはECMAScripted Webサイトルーチン用に設定されていますが、コールバックルーチンを再検討する理由の1つです。
それが人々を混乱させるものです……これらのベンダーによる非常に基本的なHTTPリクエストの実装とJavascriptされたトリックは、明確ではない言語に階層化されています。次に、非常に単純なコーディングで解決できる不必要なことをすべて実行する巨大なWebアプリケーションを構築します。
私はまだASP.NETを使用および推奨しています。それは長い道のりと素晴らしいシステムです。しかし、実際に何が行われているのかを確認すれば、これらのフレームワークをカスタマイズしてかなり単純化して改善できるため、使用する前に基本的なことを理解する人が増えると助かります。
ポストバックは、リクエストがサーバーに送信されるときに発生し、各リクエストのセキュリティに関する詳細を提供する必要はありません。
サーバーが他のページのコールバックを要求したとき