ワイヤレスアプリケーションプロトコル

WAP規格はプロトコルスイートまたはスタック^{[ 8 ]}を規定しており、WAP機器とソフトウェアをGSMやIS-95 （ CDMAとも呼ばれる）などの異なるネットワーク技術と相互運用可能にしている。

The bottom-most protocol in the suite, the Wireless Datagram Protocol (WDP), functions as an adaptation layer that makes every data network look a bit like UDP to the upper layers by providing unreliable transport of data with two 16-bit port numbers (origin and destination). All the upper layers view WDP as one and the same protocol, which has several "technical realizations" on top of other "data bearers" such as SMS, USSD, etc. On native IP bearers such as GPRS, UMTS packet-radio service, or PPP on top of a circuit-switched data connection, WDP is in fact exactly UDP.

Wireless Transport Layer Security (WTLS), an optional layer, provides a public-key cryptography-based security mechanism similar to the Internet's Transport Layer Security (TLS) protocol. Whether or not WTLS is implemented depends on the required level of security for a given WAP application, and this layer provides data integrity, privacy, authentication, and denial-of-service protection features.^[9]

WTP provides transaction support adapted to the wireless world. It provides for transmitting messages reliably, similarly to TCP. However WTP is more effective than TCP when packets are lost, a common occurrence with 2G wireless technologies in most radio conditions. WTP does not misinterpret the packet loss as network congestion, unlike TCP.

WAP sites are written in WML, a markup language.^[10] WAP provides content in the form of decks, which have several cards: decks are similar to HTML web pages as they are the unit of data transmission used by WAP and each have their own unique URL, and cards are elements such as text or buttons which can be seen by a user.^[11] WAP has URLs which can be typed into an address bar which is similar to URLs in HTTP. Relative URLs in WAP are used for navigating within a deck, and Absolute URLs in WAP are used for navigating between decks.^[10] WAP was designed to operate in bandwidth-constrained networks by using data compression before transmitting data to users.^[12]

このプロトコル スイートにより、端末はHTTPまたはHTTPSに相当するリクエストをWAP ゲートウェイに送信できます。ゲートウェイはリクエストをプレーン HTTP に変換します。WAP デッキはプロキシを介して配信され、プロキシは WML 構文の正しさと一貫性をチェックし、リソースが限られた携帯電話でのユーザー エクスペリエンスを向上させます。^{[ 5 ]} WAP 要素は各モバイル デバイスの機能に対応するためのヒントとして扱われるため、WAP はコンテンツが画面にどのように表示されるかを保証することはできません。たとえば、一部の携帯電話はグラフィック/画像や斜体をサポートしていません。^{[ 11 ]}

ワイヤレスアプリケーション環境（WAE）領域は、アプリケーション固有のマークアップ言語を定義します。

WAPバージョン1.Xでは、WAEの主要言語はWireless Markup Language（WML）です。WAP 2.0では、主要マークアップ言語はXHTML Mobile Profileです。

WAPプッシュは、最小限のユーザー操作でWAPコンテンツをモバイル端末にプッシュできるようにするために仕様に組み込まれました。WAPプッシュは基本的に、WAPアドレスへのリンクを含む特別にエンコードされたメッセージです。^{[ 13 ]}

WAP Pushは無線データグラムプロトコル（WDP）の上に規定されているため、GPRSやSMSなど、WDPがサポートする任意のベアラ上で配信できます。^{[ 14 ]}ほとんどのGSMネットワークにはさまざまな改良されたプロセッサがありますが、ネットワークからのGPRSアクティベーションは一般的にサポートされていないため、WAP PushメッセージはSMSベアラ上で配信する必要があります。

WAP Pushを受信すると、WAP 1.2（以降）対応のハンドセットは、ユーザーにWAPコンテンツにアクセスするオプションを自動的に提供します。これはWAP Push SI（サービス表示）とも呼ばれます。^{[ 14 ]} WAP Push SL（サービス読み込み）と呼ばれるバリアントは、ユーザーの操作なしにブラウザを直接開き、WAPコンテンツを表示します。この動作はセキュリティ上の懸念を引き起こすため、一部のハンドセットは、ユーザー操作を提供することで、WAP Push SLメッセージをSIと同じように処理します。

WAPプッシュを処理し、IPまたはSMSベアラ経由で配信するネットワークエンティティは、プッシュプロキシゲートウェイ（PPG）として知られています。^{[ 14 ]}

2002年に再設計されたバージョン2.0がリリースされました。これは、エンドツーエンドHTTPを使用した簡略化されたXHTMLを使用し、ゲートウェイとそれとの通信に使用されるカスタムプロトコルスイートを削除しています。WAPゲートウェイはWAP 2.0と併用できますが、このシナリオでは標準プロキシサーバーとして使用されます。WAPゲートウェイの役割は、変換から各リクエストへの追加情報の追加へと変化します。これはオペレーターによって設定され、電話番号、位置情報、請求情報、端末情報などが含まれる可能性があります。

モバイルデバイスは、 WAP 2.0で定義されたマークアップ言語であるXHTMLモバイルプロファイル（XHTML MP）を処理します。これはXHTMLのサブセットであり、 XHTML Basicのスーパーセットです。XHTML MPは、WAP CSSと呼ばれるカスケーディングスタイルシート（ CSS ）のバージョンをサポートしています。

マルチメディアメッセージングサービス（MMS）は、WAPとSMSを組み合わせたもので、画像メッセージの送信を可能にする。

WAPサイトを最初に立ち上げたのは、1999年10月にオランダの携帯電話事業者Telfort BVでした。このサイトはChristopher BeeとEuan McLeodがサイドプロジェクトとして開発し、 Nokia 7110の発売と同時に公開されました。マーケターはWAPの導入時に大々的に宣伝し^{[ 18 ]} 、ユーザーはWAPが固定（非モバイル）インターネットアクセスと同等のパフォーマンスを発揮すると期待しました。 英国の通信事業者の1つであるBT Cellnetは、漫画のWAPユーザーがニューロマンサーのような「情報空間」をサーフィンしている様子を描いた広告キャンペーンを展開しました[ 19 ]。しかし^、速度、使いやすさ、外観、相互運用性に関しては、1999年に最初の端末が発売されたとき、現実は期待を大きく下回りました^{[ 20 ] [ 21 ]。そのため、「Worthless Application Protocol」 [ 22 ]} 、 「Wait And Pay」^{[ 23 ]}、WAPlash などの皮肉なフレーズが広く使われるようになりました。 ^{[ 24 ]}

2003年から2004年にかけて、無線サービス（Vodafone Live! 、T-Mobile T-Zones、その他簡単にアクセスできるサービスなど）の導入により、WAPはより力強く復活しました。通信事業者の収益はGPRSおよびUMTSデータの転送によって生み出され、これは従来のWebサイトやISPが使用するビジネスモデルとは異なります。モバイルデータ協会によると、英国におけるWAPトラフィックは2003年から2004年にかけて倍増しました。^{[ 25 ]}

2013年までに、WAPの利用はほぼ消滅した。その後、ほとんどの大手企業やウェブサイトはWAPの利用を終了し、モバイルウェブにおける主流技術ではなくなってから数年が経過している。

最新の携帯電話向けウェブブラウザのほとんどは、HTML、CSS、およびJavaScriptの大部分をサポートしており、ウェブページの互換性のためにWAPマークアップを使用する必要はありません。HTMLをサポートする携帯電話のリストは膨大で、すべてのAndroid端末、すべてのバージョンのiPhone端末、すべてのBlackBerry端末、すべてのWindows Phone搭載端末、および複数のNokia端末が含まれます。

WAPは日本で大きな成功を収めた。最大手の通信事業者であるNTTドコモは自社システムであるiモードを優先しWAPを採用しなかったが、ライバル事業者のKDDI（au）とソフトバンクモバイル（旧ボーダフォンジャパン）はともにWAP技術を成功裏に展開した。特にソフトバンクモバイルの着信音サービスや着信音動画サービスはWAPをベースとしていた。ヨーロッパと同様に、日本でもHTML対応スマートフォンが普及するにつれ、2010年代にはWAPとiモードの利用は減少した。

米国におけるWAPの普及が阻害されたのは、多くの携帯電話事業者がデータサポートのために別途の有効化と追加料金を要求したこと、そして通信会社が信号キャリアのライセンスの下で運営されている承認済みのデータプロバイダーのみにデータアクセスを制限しようとしたことが原因だった。

この問題を認識して、米国連邦通信委員会（FCC）は2007年7月31日に、22メガヘルツ幅の「アッパー700MHz Cブロック」スペクトルのライセンス取得者は、顧客、デバイスメーカー、サードパーティのアプリケーション開発者などが、この特定のライセンスネットワーク帯域で動作する際に、任意のデバイスやアプリケーションを使用できるワイヤレスプラットフォームを実装しなければならないという命令を出した。^{[ 26 ] [ 27 ]}

独特なWML言語は、ユーザーを従来のHTMLウェブから切り離し、WAPユーザーが利用できるのはネイティブのWAPコンテンツとWeb-to-WAPプロキシコンテンツのみとなった。

多くの無線通信事業者は、WAPサービスを「オープン」として販売し、ユーザーがWMLで表現されインターネット上に公開されているあらゆるサービスにアクセスできるようにした。しかし、同時に、クライアントが最初にアクセスするページが、自社が厳密に管理する独自の「無線ポータル」であることを保証した。^{[ 28 ]}

一部の通信事業者は、端末のブラウザのアドレスバーの編集やアクセスも無効にしました。端末外へのアクセスを容易にするため、ハードコードされたホームページからリンクされたページのフォームにアドレスバーが用意されました。これにより、通信事業者はURLによる端末外のWMLサイトのフィルタリングを実装しやすくなり、将来的にすべてのユーザーをウォールドガーデンモデルに切り替えることを決定した場合にアドレスバーを無効にすることも可能になります。電話のキーボードで完全修飾URLを入力するのは困難であるため、ほとんどのユーザーは「ポータル外」またはウォールドガーデンから出ることを諦めるでしょう。サードパーティが通信事業者のワイヤレスポータルに独自のエントリを掲載することを許可しないことで、通信事業者は貴重な機会を自ら断ち切っていると主張する人もいます。一方、一部の通信事業者は、顧客は通信事業者がエクスペリエンスを管理し、このような制約のある端末では、あまり多くのサービスへのアクセスを避けることを望んでいたと主張しています。

端末要件の仕様不足：初期のWAP規格には、多くのオプション機能と不十分な要件が含まれていたため、規格に準拠したデバイスでも必ずしも適切に相互運用できるとは限りませんでした。その結果、携帯電話の実際の動作に大きなばらつきが生じました。これは主に、WAPサービスの実装者や携帯電話メーカーが規格のコピーや適切なハードウェア、標準ソフトウェアモジュールを入手できなかったためです。

例えば、一部の携帯電話機種では、1KBを超えるサイズのページを受け付けなかったり、クラッシュしたりすることがありました。また、デバイスのユーザーインターフェースも仕様が不十分でした。例えば、アクセスキー（リスト内の4番目のリンクに直接アクセスするために「4」を押す機能など）の実装方法は、携帯電話機種によって様々でした（ブラウザがリンクの横にアクセスキー番号を自動的に表示する場合もあれば、表示しない場合もあり、アクセスキー自体が実装されていない場合もありました）。

ユーザーインターフェース機能の制約：初期のWAP端末のように、小型の白黒画面と少ないボタンを備えた端末では、ユーザーに多くの情報を表示することが困難であり、これが他の問題をさらに悪化させていました。つまり、WAPの真のコンセプトである、リソースが限られたデバイス上でユーザーインターフェースを設計する際には、特に注意を払う必要がありました。

ウェブ開発とは対照的に、WAP開発はWML仕様の厳格な要件と、多種多様な無線デバイスでの最適化とテストの要求により、非常に厳しく、ほとんどのプロジェクトの完了に必要な時間を大幅に延長させた。2009年現在しかし、複数のモバイルデバイスがXHTMLをサポートし、Adobe Go LiveやDreamweaverなどのプログラムが改良されたWebオーサリングツールを提供するようになったことで、より多くの新しいデバイスでアクセス可能なコンテンツを作成することが容易になった。

ユーザーエージェントプロファイリングツールの不足：Webサイトは、提供されたユーザーエージェントタイプに基づいてページをデバイスの機能に合わせて調整することで、複数のデバイスモデルにコンテンツを提供します。しかし、WML向けに存在していた開発キットにはこの機能がありませんでした。そのため、サイトホストは、リクエストがモバイルデバイスからなのか、より大型で高性能なデバイスからなのかを判断することがほぼ不可能になりました。非公式で規格に準拠していない製品の仕様には、有用なプロファイリング機能やデバイス機能のデータベースは組み込まれていませんでした。

無線通信事業者によるコンテンツプロバイダーの軽視：一部の無線通信事業者は「構築すれば顧客が集まる」という戦略を採用し、データ伝送と端末を提供するだけで、コンテンツプロバイダーがインターネット上でサービスを公開し、WAPへの投資が実用化されるのを待つことにした。しかし、コンテンツプロバイダーは、複雑な開発ルートを進むための支援やインセンティブをほとんど受けなかった。一方、特に日本（下記参照）では、コンテンツプロバイダーコミュニティとのより徹底した対話が行われ、それが日本のiモードやフランスのギャラリーサービスといった、より現代的で成功したWAPサービスに反映された。^{[ 29 ]}