shared

class var shared: URLSession { get }

Discussion 議論

For basic requests, the URLSession class provides a shared singleton session object that gives you a reasonable default behavior for creating tasks. Use the shared session to fetch the contents of a URL to memory with just a few lines of code. 基本的なリクエストに対して、URLSessionクラスはある共有シングルトンセッションオブジェクトを提供します、それはあなたにある道理にかなった省略時の挙動を、タスクそれらを作成するために与えます。共有セッションを使って、ほんの数行のコードで、URLの内容をメモリに取ってきてください。

Unlike the other session types, you don’t create the shared session; you merely access it by using this property directly. As a result, you don’t provide a delegate or a configuration object. 他のセッション型と違って、あなたはその共有セッションを作成しません；あなたは、このプロパティを直接に使うことで、単にそれにアクセスします。結果として、あなたは委任先または構成設定オブジェクトを提供しません。

Limitations of the Shared Session 共有セッションの限界

Because the shared session has neither a delegate nor a customizable configuration object, the shared session has important limitations: 共有セッションは委任先もカスタマイズできる構成設定オブジェクトも持ちません、そのため共有セッションは重大な限界を持ちます：

• You can’t obtain data incrementally as it arrives from the server. あなたは、データを漸次的にそれがサーバから到着するにつれて入手できません。

• You can’t significantly customize the default connection behavior. あなたは、省略時の接続挙動を大きくカスタマイズできません。

• Your ability to perform authentication is limited. あなたの認証を実行する能力は、制限されます。

• You can’t perform background downloads or uploads when your app isn’t running. あなたは、バックグラウンドダウンロードまたはアップロードをあなたのアプリが動作していない時に実行できません。

The shared session uses the shared URLCache, HTTPCookieStorage, and URLCredentialStorage objects, uses a shared custom networking protocol list (configured with registerClass(_:) and unregisterClass(_:)), and is based on a default configuration. 共有セッションは、共有URLCache、HTTPCookieStorage、そしてURLCredentialStorageオブジェクトを使用します、共有されるあつらえのネットワークプロトコルリストを使用します（registerClass(_:)とunregisterClass(_:)で構成設定されます）、そして省略時の構成設定に基づきます。

In general, when working with a shared session, you should avoid customizing the cache, cookie storage, or credential storage (unless you are already doing so with NSURLConnection). There’s a good chance that you’ll outgrow the capabilities of the default session, at which point you’ll have to rewrite all of those customizations to work with your custom URL sessions. 一般に、共有セッションを扱う場合、あなたはキャッシュ、クッキーストレージ、または資格情報ストレージのカスタマイズを避けるべきです（あなたが既にNSURLConnectionでそうしている場合を除いて）。あなたが省略時セッションのもつさまざまな能力から脱却する十分な可能性があります、その時点であなたは、あなたのあつらえのURLセッションを扱うそれらあつらえのものの全てを書き直さなければなりません。

In other words, if you’re doing anything with caches, cookies, authentication, or custom networking protocols, you should probably be using a default session instead of the shared session. 言い換えれば、あなたが何かをキャッシュ、クッキー、認証、またはあつらえのネットワークプロトコルで行っているならば、あなたはおそらく省略時のセッションを使っているべきです、共有セッションではなくて。