複雑なリクエストになります。以下のようなものです。リクエストで、ブラウザはサーバからリソースを取得します。よってどんどん複雑になってきました。導入に伴って以下が変わっています。古めかしいインタフェースにとらわれる事無く実装ができます。議論とともに進んでいく予定のようです。使って完全に再現できる筈です。リクエストとして一番低レベルでした。そのままブラウザから使えるようにしてしまえ、という感じのコンセプトです。サーバが立ててしまう可能性があるのです。名前解決するなんてことができてしまうかもしれません。持ってくる事は、セキュリティのサンドボックス化が非常に気になると思います。実装ではそこが非常に重要になります。中には、「それこそが標準化がリソースを裂くべきところだ」と明記されています。提供に注力するべきという方針です。完結すると、今まで拡張やプラグインで無茶したコードのセキュリティホールによって発生していた、ネイティブ層まで突き抜けるような脆弱性が、減少する可能性も考えられます。APIオフライン化するために必要な機能をモデル化すると以下の三つに大別することができました。API」だとされている感がありますが、それは使い方の凡例の一つです。各々は別にチュートリアルに書かれてる通り、オフライン化するために「しか」使えないわけではありません。別のコンテキストで動作する(別のスレッドが立っているイメージ)環境を提供します。飛んで来たメッセージをイベントで受け取ることができます。この事をふまえて、よく言われている「オフラインアプリ」や「プロキシ」として使う事もできるというだけであって、そう使わないといけないというものではありません。ブラウザに返したりというインタフェースが整ったからです。https://slightlyoff.github.io/ServiceWorker/spec/service_worker/Caches外部から取得したリソースのキャッシュを管理するためのオブジェクトです。保存するといったことが可能になるのです。違い、一部のリソースだけキャッシュを更新すると言った事が柔軟に可能です。変わるオフラインアプリの作成で注目されているのはこの部分です。response));});しかし、オフライン化のためにしか使ってはいけない訳ではなく、例えばオンライン状態でも純粋なキャッシュとして利用して、パフォーマンスの向上などを行う事もできます。手軽に扱うことができます。なんで無かったのかというレベルです。やるか、自分でパースするしかありませんでした。ついては、執筆時点で実装しているブラウザはないようなので、サンプルです。扱えるようになったためと言えます。オブジェクトを内部で使えど、外に公開するためには用いないということです。文字列として公開すべきという旨が書かれています。(https://fetch.spec.whatwg.org/#request-class)片手間な正規表現で処理していたスクリプトは、すぐにでもこのクラスで置き換える方がいいでしょう。するくらいが良いと思います。パラメータ部分を扱うためのオブジェクトです。形式の表現を得ることができます。シリアライズ時には適切にエンコードされた文字列が得られます。していた処理があったとすれば、この実装で置き換える事でブラウザと完全に互換な実装にできます。してこれを使う事が考えられます。して送るなどのことはできません。それだとちょっと微妙なので、提案しました。扱うオブジェクトです。オブジェクトを含む事ができます。アップロードが可能です。詰め替える必要があります。生成できるようにする方向で動いているので、それが実装されたら以下のようになるでしょう。ベースで設計されています。統一されつつあります。