API の説明に入る前に、push の全容を大まかに見ていきましょう。その後、個々のトピックや API について確認することで、その重要性と理由がわかるようになります。
push を実装する主な 3 つのステップは次のとおりです。
- プッシュするユーザーをサブスクライブするクライアント側のロジック(メッセージをプッシュするユーザーを登録するウェブアプリの JavaScript と UI)を追加する。
- ユーザーのデバイスへのプッシュ メッセージをトリガーするバックエンドまたはアプリケーションからの API 呼び出し。
- デバイスに push が到着したときに「push イベント」を受け取る Service Worker の JavaScript ファイル。通知を表示できるのはこの JavaScript です。
各ステップの内容についてもう少し詳しく見てみましょう。
ステップ 1: クライアント側
最初のステップは、メッセージをプッシュできるようにユーザーを「登録」することです。
ユーザーの登録には 2 つのことが必要です。まず、push メッセージを送信するための権限をユーザーから取得します。次に、ブラウザから PushSubscription
を取得します。
PushSubscription
には、そのユーザーに push メッセージを送信するために必要なすべての情報が含まれています。これは、ユーザーのデバイスの ID と考えることができます。
この処理はすべて、Push API を使用して JavaScript で行います。
ユーザーをサブスクライブする前に、一連の「アプリケーション サーバーキー」を生成する必要があります。これについては後で説明します。
アプリケーション サーバーキーは VAPID キーとも呼ばれ、サーバーに固有のものです。これにより、push サービスはユーザーをサブスクライブしたアプリケーション サーバーを認識し、そのユーザーへの push メッセージをトリガーしているサーバーと同じサーバーであることを確認できます。
ユーザーを登録して PushSubscription
を取得したら、PushSubscription
の詳細をバックエンド / サーバーに送信する必要があります。サーバーで、このサブスクリプションをデータベースに保存し、それを使用してユーザーに push メッセージを送信します。
ステップ 2: push メッセージを送信する
ユーザーに push メッセージを送信するには、push サービスに対して API 呼び出しを行う必要があります。この API 呼び出しには、送信するデータ、メッセージの送信先、メッセージの送信方法に関する条件が含まれます。通常、この API 呼び出しはサーバーから行われます。
次のようなことを自問してみましょう。
- プッシュ サービスの対象と対象
- API の外観JSON や XML などでしょうか?
- API でできること
プッシュ サービスの対象と対象
push サービスは、ネットワーク リクエストを受け取って検証し、プッシュ メッセージを適切なブラウザに配信します。ブラウザがオフラインの場合、メッセージはブラウザがオンラインになるまでキューに追加されます。
各ブラウザは任意のプッシュ サービスを使用できますが、これはデベロッパーが制御することはできません。すべての push サービスが同じ API 呼び出しを想定しているので、これは問題にはなりません。つまり、push サービスが誰であるかを気にする必要はありません。必要なのは、API 呼び出しが有効であることを確認することだけです。
push メッセージをトリガーするための適切な URL(つまり push サービスの URL)を取得するには、PushSubscription
の endpoint
値を確認するだけです。
PushSubscription から取得する値の例を次に示します。
{
"endpoint": "https://random-push-service.com/some-kind-of-unique-id-1234/v2/",
"keys": {
"p256dh": "BNcRdreALRFXTkOOUHK1EtK2wtaz5Ry4YfYCA_0QTpQtUbVlUls0VJXg7A8u-Ts1XbjhazAkj7I99e8QcYP7DkM=",
"auth": "tBHItJI5svbpez7KI4CCXg=="
}
}
この場合のエンドポイントは [https://random-push-service.com/some-kind-of-unique-id-1234/v2/] です。push サービスは「random-push-service.com」で、各エンドポイントは「some-kind-of-unique-id-1234」でユーザーに一意です。push を使い始めると、このパターンに気付くでしょう。
サブスクリプションの鍵については後ほど説明します。
API の外観
前述のように、すべてのウェブ push サービスは同じ API 呼び出しを想定しています。この API は、ウェブプッシュ プロトコルです。push サービスに対して API 呼び出しを行う方法を定義する IETF 標準です。
API 呼び出しでは、特定のヘッダーを設定し、データをバイト ストリームにする必要があります。この API 呼び出しを実行できるライブラリと、自分で実行する方法を見ていきます。
API でできること
この API は、データの有無にかかわらず、ユーザーにメッセージを送信する方法と、メッセージの送信方法を提供します。
push メッセージで送信するデータは暗号化する必要があります。これは、誰でも push するサービスが push メッセージで送信されたデータを閲覧できなくなるためです。使用するプッシュ サービスを決定するのはブラウザであるため、安全またはセキュアでないプッシュ サービスを使用するブラウザへの扉を開く可能性があることを考えると、これは重要です。
push メッセージをトリガーすると、push サービスは API 呼び出しを受け取り、メッセージをキューに入れます。このメッセージは、ユーザーのデバイスがオンラインになり、プッシュ サービスがメッセージを配信できるようになるまで、キューに入ったままになります。push サービスに指示できる手順は、push メッセージのキューへの入り方を定義します。
手順には次のような詳細情報が含まれます。
push メッセージの有効期間。これは、メッセージが削除されて配信されなくなるまでのキューに入れる時間を定義します。
メッセージの緊急度を定義します。これは、push サービスが優先度の高いメッセージのみを配信することで、ユーザーの電池寿命を延ばす場合に便利です。
プッシュ メッセージに「トピック」名を指定して、保留中のメッセージをこの新しいメッセージに置き換えます。
ステップ 3: ユーザーのデバイスでのプッシュ イベント
push メッセージを送信すると、push サービスは次のいずれかのイベントが発生するまで、メッセージをサーバーに保持します。
- デバイスがオンラインになり、プッシュ サービスがメッセージを配信します。
- メッセージの有効期限が切れる。この場合、push サービスはメッセージをキューから削除し、配信されなくなります。
push サービスがメッセージを配信すると、ブラウザはメッセージを受信してデータを復号し、Service Worker で push
イベントを送信します。
Service Worker は「特別な」JavaScript ファイルです。ブラウザは、ページを開かずにこの JavaScript を実行できます。この JavaScript は、ブラウザが閉じられたときでも実行できます。Service Worker には、ウェブページでは使用できない API(つまり、Service Worker スクリプト外では使用できない API)(push など)もあります。
Service Worker の「push」イベント内で、あらゆるバックグラウンド タスクを実行できます。分析の呼び出し、ページをオフラインでキャッシュして、通知を表示できます。
プッシュ メッセージのフローは以上です。
次のステップ
- ウェブでのプッシュ通知の概要
- プッシュの仕組み
- ユーザーの登録
- 権限の UX
- ウェブプッシュ ライブラリを使用したメッセージの送信
- ウェブのプッシュ プロトコル
- push イベントの処理
- 通知の表示
- 通知の動作
- 一般的な通知パターン
- プッシュ通知に関するよくある質問
- 一般的な問題とバグの報告