initial commit

5 files changed, 1112 insertions, 0 deletions

diff --git a/files/ja/learn/server-side/first_steps/client-server_overview/index.html b/files/ja/learn/server-side/first_steps/client-server_overview/index.html
new file mode 100644
index 0000000000..a99e34eff0
--- /dev/null
+++ b/files/ja/learn/server-side/first_steps/client-server_overview/index.html
@@ -0,0 +1,329 @@
+---
+title: クライアント - サーバの概要
+slug: Learn/Server-side/First_steps/Client-Server_overview
+tags:
+  - Beginner
+  - CodingScripting
+  - イントロダクション
+  - ガイド
+  - サーバ
+  - サーバサイドプログラミング
+  - 学習
+translation_of: Learn/Server-side/First_steps/Client-Server_overview
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">サーバサイドプログラミングの目的と潜在的な利点を知ったので、サーバがブラウザーから "動的リクエスト" を受け取ったときに起こることを詳細に検討します。ほとんどの Web サイトのサーバサイドコードは同様の方法でリクエストとレスポンスを処理するので、これは自身のコードの大部分を書くときに何が必要かを理解するのに役立ちます。</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">前提条件</th>
+   <td>基本的なコンピュータリテラシー。Web サーバの基本的な理解。</td>
+  </tr>
+  <tr>
+   <th scope="row">目的</th>
+   <td>動的な Web サイトにおけるクライアントとサーバのやりとり、特にサーバサイドのコードで実行する必要がある操作を理解する。</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>私たちはまだコードを書くために使う Web フレームワークを選択していないので、議論には本当のコードはありません！ ただし、どのプログラミング言語または Web フレームワークを選択したかに関係なく、記述された動作はサーバ側のコードで実装する必要があるため、この説明は依然として非常に重要です。</p>
+
+<h2 id="Web_サーバと_HTTP_(入門書)">Web サーバと HTTP (入門書)</h2>
+
+<p>Web ブラウザは、<strong>H</strong>yper<strong>T</strong>ext<strong> T</strong>ransfer <strong>P</strong>rotocol (<a href="/ja/docs/Web/HTTP">HTTP</a>) を使用して <a href="/ja/docs/Learn/Common_questions/What_is_a_web_server">Web サーバ</a>と通信します。Web ページのリンクをクリックしたり、フォームを送信したり、検索を実行したりすると、ブラウザは <em>HTTP リクエスト</em>をサーバに送信します。</p>
+
+<p>このリクエストに含まれるもの:</p>
+
+<ul>
+ <li>対象のサーバとリソース (HTML ファイル、サーバ上の特定のデータポイント、実行するツールなど) を識別する URL</li>
+ <li>必要なアクション (たとえば、ファイルを取得したり、データを保存または更新したりするため) を定義するメソッド。さまざまなメソッド/動詞とそれに関連するアクションを以下にリストします。
+  <ul>
+   <li><code>GET</code>: 特定のリソース (製品に関する情報を含む HTML ファイル、製品のリストなど) を取得します。</li>
+   <li><code>POST</code>: 新しいリソース (たとえば、新しい記事をWikiに追加したり、新しい連絡先をデータベースに追加したりします) を作成します。</li>
+   <li><code>HEAD</code>: <code>GET</code> のように body を取得せずに、特定のリソースに関するメタデータ情報を取得します。たとえば、リソースが最後に更新された時刻を調べるために <code>HEAD</code> リクエストを使用し、リソースが変更された場合にのみ (より "高価な") <code>GET</code> リクエストを使用します。</li>
+   <li><code>PUT</code>: 既存のリソースを更新します (または、存在しない場合は新しいリソースを作成します)。</li>
+   <li><code>DELETE</code>: 指定したリソースを削除します。</li>
+   <li><code>TRACE</code>, <code>OPTIONS</code>, <code>CONNECT</code>, <code>PATCH</code>: これらの動詞は、あまり一般的ではない高度な作業のためのものなので、ここでは説明しません。</li>
+  </ul>
+ </li>
+ <li>追加情報 (たとえば、HTML フォームデータ) をリクエストと共にエンコードすることができます。情報は次のようにエンコードできます。
+  <ul>
+   <li>URL パラメータ: <code>GET</code> リクエストは、サーバに送信された URL に名前と値のペアを末尾に追加することで、データをエンコードします (例：<code>http://mysite.com<strong>?name=Fred&amp;age=11</strong></code>)。URL パラメータから URL の残りの部分を区切る疑問符 (<code>?</code>)、関連する値から各名前を区切る等号 (<code>=</code>)、および各ペアを区切るアンパサンド (<code>&amp;</code>) が常にあります。URL パラメータは、ユーザが変更して再送信することができるため、本質的に「安全ではありません」。結果として、URL パラメータの <code>GET</code> リクエストは、サーバ上のデータを更新するリクエストには使用されません。</li>
+   <li><code>POST</code> データ: <code>POST</code> リクエストは新しいリソースを追加し、そのデータはリクエストボディ内にエンコードされます。</li>
+   <li><span style="display: none;"> </span>クライアントサイド Cookie : Cookie には、クライアントに関するセッションデータが含まれており、サーバはそれをログイン状態とリソースへの権限/アクセスを判断するために使用できます。</li>
+  </ul>
+ </li>
+</ul>
+
+<p>Web サーバはクライアントリクエストメッセージを待ち、メッセージが到着したときにそれらを処理し、HTTP レスポンスメッセージで Web ブラウザにレスポンスします。レスポンスには、リクエストが成功したかどうかを示す <a href="/ja/docs/Web/HTTP/Status">HTTP レスポンスステータスコード</a> (<span class="tlid-translation translation" lang="ja"><span title="">例: 成功した場合は "</span></span><code>200 OK</code><span class="tlid-translation translation" lang="ja"><span title="">"、リソースが見つからない場合は "</span></span><code>404 Not Found</code><span class="tlid-translation translation" lang="ja"><span title="">"、ユーザがリソースを見ることを許可されていない場合は "</span></span><code>403 Forbidden</code><span class="tlid-translation translation" lang="ja"><span title="">"など) </span></span>が含まれます。<code>GET</code> リクエストに対する成功したレスポンスの本文には、リクエストされたリソースが含まれます。</p>
+
+<p>HTML ページが返されると、Web ブラウザによってレンダリングされます。 処理の一部として、ブラウザは他のリソースへのリンクを発見することができ (例えば HTML ページは通常 JavaScript と CSS ページを参照します)、これらのファイルをダウンロードするために別々の HTTP リクエストを送信します。</p>
+
+<p>静的および動的 Web サイト (以降のセクションで説明) は、まったく同じ通信プロトコル/パターンを使用しています。</p>
+
+<h3 id="GET_リクエストレスポンス_例">GET リクエスト/レスポンス 例</h3>
+
+<p>リンクをクリックするか (検索エンジンホームページのように) サイトを検索することで簡単な <code>GET</code> リクエストをすることができます。たとえば、MDNで「クライアント - サーバの概要」という用語を検索したときに送信される HTTP リクエストは、次のようになります (メッセージの一部はあなたのブラウザや設定に依存するので、同一にはなりません)。</p>
+
+<div class="note">
+<p>HTTP メッセージのフォーマットは「Web 標準」(<a href="http://www.rfc-editor.org/rfc/rfc7230.txt">RFC7230</a>) で定義されています。このレベルの詳細を知る必要はありませんが、少なくとも今、これら全てがどこから来たのかを知っています！</p>
+</div>
+
+<h4 id="リクエスト">リクエスト</h4>
+
+<p>リクエストの各行にはそれに関する情報が含まれています。 最初の部分は<strong>ヘッダー</strong>と呼ばれ、<a href="/ja/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML">HTML head</a> に HTML 文書に関する有用な情報が含まれるのと同じで、リクエストに関する有用な情報が含まれます (ただし、実際のコンテンツ自体は含まれません)。</p>
+
+<pre>GET https://developer.mozilla.org/en-US/search?q=client+server+overview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Pragma: no-cache
+Cache-Control: no-cache
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/
+Accept-Encoding: gzip, deflate, sdch, br
+<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true
+</pre>
+
+<p>1行目と2行目には、上記で説明したほとんどの情報が含まれています。</p>
+
+<ul>
+ <li>リクエストのタイプ (<code>GET</code>)</li>
+ <li>ターゲットリソースの URL (<code>/en-US/search</code>)</li>
+ <li>URL パラメータ (<code>q=client%2Bserver%2Boverview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev</code>)</li>
+ <li>ターゲット/ホストの Web サイト (developer.mozilla.org)</li>
+ <li>最初の行の終わりには、特定のプロトコルバージョンを識別する短い文字列 (<code>HTTP/1.1</code>) も含まれています。</li>
+</ul>
+
+<p>最後の行にはクライアントサイドの Cookie に関する情報が含まれています。この場合、Cookie にはセッションを管理するための ID (<code>Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; ...</code>) が含まれています。</p>
+
+<p>残りの行には、使用されているブラウザとそれが処理できるレスポンスの種類に関する情報が含まれています。たとえば、次のようになります。</p>
+
+<ul>
+ <li>私のブラウザ (<code>User-Agent</code>) は Mozilla Firefox (<code>Mozilla/5.0</code>) です。</li>
+ <li>gzip 圧縮情報 (<code>Accept-Encoding: gzip</code>) を受け入れることができます。</li>
+ <li>指定された文字セット (<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>) および<span class="tlid-translation translation" lang="ja"><span title="">言語</span></span> (<code>Accept-Language: de,en;q=0.7,en-us;q=0.3</code>) を受け入れることができます。</li>
+ <li><code>Referer</code> 行は、このリソースへのリンク (つまり、要求の発信元、<code>https://developer.mozilla.org/en-US/</code>) を含んだ Web ページのアドレスを示します。</li>
+</ul>
+
+<p>HTTP リクエストもボディを持つことができますが、この場合は空です。</p>
+
+<h4 id="レスポンス">レスポンス</h4>
+
+<p>このリクエストに対するレスポンスの最初の部分を以下に示します。ヘッダーには、次のような情報が含まれています。</p>
+
+<ul>
+ <li>最初の行にはレスポンスコード <code>200 OK</code> が含まれています。これはリクエストが成功したことを示しています。</li>
+ <li>レスポンスが <code>text/html</code> フォーマットの (<code>Content-Type</code>) であることがわかります。</li>
+ <li>また、UTF-8 文字セット(<code>Content-Type: text/html; charset=utf-8</code>) が使用されていることもわかります。</li>
+ <li>head はそれがどれくらい大きいかも教えてくれます (<code>Content-Length: 41823</code>)。</li>
+</ul>
+
+<p>メッセージの最後に <strong>body</strong> があります。これにはリクエストによって返された実際の HTML が含まれています。</p>
+
+<pre class="brush: html line-numbers language-html"><code class="language-html">HTTP/1.1 200 OK
+Server: Apache
+X-Backend-Server: developer1.webapp.scl3.mozilla.com
+Vary: Accept,Cookie, Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:11:31 GMT
+Keep-Alive: timeout=5, max=999
+Connection: Keep-Alive
+X-Frame-Options: DENY
+Allow: GET
+X-Cache-Info: caching
+Content-Length: 41823
+
+
+
+<span class="doctype token">&lt;!DOCTYPE html&gt;</span>
+<span class="tag token"><span class="tag token"><span class="punctuation token">&lt;</span>html</span> <span class="attr-name token">lang</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>en-US<span class="punctuation token">"</span></span> <span class="attr-name token">dir</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>ltr<span class="punctuation token">"</span></span> <span class="attr-name token">class</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>redesign no-js<span class="punctuation token">"</span></span>  <span class="attr-name token">data-ffo-opensanslight</span><span class="attr-value token"><span class="punctuation token">=</span>false</span> <span class="attr-name token">data-ffo-opensans</span><span class="attr-value token"><span class="punctuation token">=</span>false</span> <span class="punctuation token">&gt;</span></span>
+<span class="tag token"><span class="tag token"><span class="punctuation token">&lt;</span>head</span> <span class="attr-name token">prefix</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>og: http://ogp.me/ns#<span class="punctuation token">"</span></span><span class="punctuation token">&gt;</span></span>
+  <span class="tag token"><span class="tag token"><span class="punctuation token">&lt;</span>meta</span> <span class="attr-name token">charset</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>utf-8<span class="punctuation token">"</span></span><span class="punctuation token">&gt;</span></span>
+  <span class="tag token"><span class="tag token"><span class="punctuation token">&lt;</span>meta</span> <span class="attr-name token">http-equiv</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>X-UA-Compatible<span class="punctuation token">"</span></span> <span class="attr-name token">content</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>IE=Edge<span class="punctuation token">"</span></span><span class="punctuation token">&gt;</span></span>
+  <span class="tag token"><span class="tag token"><span class="punctuation token">&lt;</span>script</span><span class="punctuation token">&gt;</span></span><span class="language-javascript script token"><span class="punctuation token">(</span><span class="keyword token">function</span><span class="punctuation token">(</span>d<span class="punctuation token">)</span> <span class="punctuation token">{</span> d<span class="punctuation token">.</span>className <span class="operator token">=</span> d<span class="punctuation token">.</span>className<span class="punctuation token">.</span><span class="function token">replace</span><span class="punctuation token">(</span><span class="regex token">/\bno-js/</span><span class="punctuation token">,</span> <span class="string token">''</span><span class="punctuation token">)</span><span class="punctuation token">;</span> <span class="punctuation token">}</span><span class="punctuation token">)</span><span class="punctuation token">(</span>document<span class="punctuation token">.</span>documentElement<span class="punctuation token">)</span><span class="punctuation token">;</span></span><span class="tag token"><span class="tag token"><span class="punctuation token">&lt;/</span>script</span><span class="punctuation token">&gt;</span></span>
+  ...</code></pre>
+
+<p>レスポンスヘッダの残りの部分には、レスポンス (たとえば、いつ生成されたか)、サーバ、およびブラウザがページを処理する方法についての情報が含まれます (たとえば、<code>X-Frame-Options: DENY</code> 行は、このページを別のサイトの {{htmlelement("iframe")}} に埋め込むことを許可しないようにブラウザに指示します)。</p>
+
+<h3 id="POST_リクエストレスポンス_例">POST リクエスト/レスポンス 例</h3>
+
+<p>HTTP <code>POST</code> は、サーバに保存する情報を含むフォームを送信したときに作成されます。</p>
+
+<h4 id="リクエスト_2">リクエスト</h4>
+
+<p>以下のテキストは、ユーザがこのサイトに新しいプロファイルの詳細を送信したときに行われる HTTP リクエストを示しています。最初の行はこのリクエストを <code>POST</code> として識別しますが、リクエストのフォーマットは前述の <code>GET</code> リクエストの例とほぼ同じです。</p>
+
+<pre class="brush: html">POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Content-Length: 432
+Pragma: no-cache
+Cache-Control: no-cache
+Origin: https://developer.mozilla.org
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Content-Type: application/x-www-form-urlencoded
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit
+Accept-Encoding: gzip, deflate, br
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _ga=GA1.2.1688886003.1471911953; ffo=true
+
+csrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&amp;user-username=hamishwillee&amp;user-fullname=Hamish+Willee&amp;user-title=&amp;user-organization=&amp;user-location=Australia&amp;user-locale=en-US&amp;user-timezone=Australia%2FMelbourne&amp;user-irc_nickname=&amp;user-interests=&amp;user-expertise=&amp;user-twitter_url=&amp;user-stackoverflow_url=&amp;user-linkedin_url=&amp;user-mozillians_url=&amp;user-facebook_url=</pre>
+
+<p>主な違いは URL にパラメータがないことです。ご覧のとおり、フォームからの情報はリクエストの本文にエンコードされています (たとえば、新しいユーザーの fullname は <code>&amp;user-fullname=Hamish+Willee</code> を使用して設定されます)。</p>
+
+<h4 id="レスポンス_2">レスポンス</h4>
+
+<p>リクエストからのレスポンスは以下のとおりです。ステータスコード "<code>302 Found</code>" は、投稿が成功したこと、および <code>Location</code> フィールドで指定されたページを読み込むために2番目の HTTP リクエストを発行する必要があることをブラウザに通知します。その他の点では、この情報は GET リクエストへのレスポンスに関する情報と似ています。</p>
+
+<pre class="brush: html">HTTP/1.1 302 FOUND
+Server: Apache
+X-Backend-Server: developer3.webapp.scl3.mozilla.com
+Vary: Cookie
+Vary: Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:38:13 GMT
+Location: https://developer.mozilla.org/en-US/profiles/hamishwillee
+Keep-Alive: timeout=5, max=1000
+Connection: Keep-Alive
+X-Frame-Options: DENY
+X-Cache-Info: not cacheable; request wasn't a GET or HEAD
+Content-Length: 0
+</pre>
+
+<div class="note">
+<p><strong>メモ</strong>: これらの例に示されている HTTP レスポンスとリクエストは <a href="https://www.telerik.com/download/fiddler">Fiddler</a> アプリケーションを使ってキャプチャされました、しかしあなたはウェブスニファ (例えば <a href="http://websniffer.cc/">Websniffer</a>) または <a href="https://addons.mozilla.org/en-US/firefox/addon/httpfox/">HttpFox</a> のようなブラウザ拡張を使って同様の情報を得ることができます。あなたはこれを自分で試すことができます。リンクされているツールを使用してから、サイト内を移動してプロファイル情報を編集し、さまざまなリクエストとレスポンスを確認します。最近のほとんどのブラウザには、ネットワーク要求を監視するツール (たとえば、Firefox の<a href="/ja/docs/Tools/Network_Monitor">ネットワークモニタツール</a>) もあります。</p>
+</div>
+
+<h2 id="静的サイト">静的サイト</h2>
+
+<p><em>静的サイト</em>は、特定のリソースがリクエストされたときはいつでもサーバから同じハードコードされたコンテンツを返すものです。たとえば、製品に関するページが <code>/static/myproduct1.html</code> にある場合、この同じページがすべてのユーザに返されます。サイトに他の似たような製品を追加するならば、別のページ (例えば <code>myproduct2.html</code>) を追加する必要があるでしょう。これは本当に非効率的になり始めます — 何千もの製品ページにたどり着くとどうなるでしょう？ <span class="tlid-translation translation" lang="ja"><span title="">各ページ (基本的なページテンプレート、構造など) に渡って多くのコードを繰り返すことになります。ページ構造について何か変更したい場合 (たとえば、新しい「関連商品」セクションを追加するなど)</span> <span title="">各ページを個別に変更する必要があります。</span></span></p>
+
+<div class="note">
+<p><strong>メモ</strong>: ページ数が少なく、すべてのユーザに同じコンテンツを送信したい場合は、静的サイトが優れています。ただし、ページ数が増えると、管理に多大なコストがかかる可能性があります。</p>
+</div>
+
+<p>前回の記事で見た静的サイトのアーキテクチャ図をもう一度見て、これがどのように機能するのかを要約しましょう。</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png"></p>
+
+<p>ユーザがページにナビゲートしたい場合、ブラウザはその HTML ページの URL を指定した HTTP <code>GET</code> リクエストを送信します。サーバはファイルシステムからリクエストされた文書を検索し、その文書と "<code>200 OK</code>" の <a href="/ja/docs/Web/HTTP/Status">HTTP レスポンスステータスコード</a> (成功を示す) を含む HTTP レスポンスを返します。ファイルがサーバに存在しない場合は "<code>404 Not Found</code>"、ファイルが存在するが別の場所にリダイレクトされている場合は "<code>301 Moved Permanently</code>" など、サーバは別のステータスコードを返すことがあります。</p>
+
+<p>静的サイトのサーバは可変データを格納しないため、GET リクエストを処理するだけで済みます。また、HTTP リクエストデータ (URL パラメータやクッキーなど) に基づいてレスポンスを変更することもありません。</p>
+
+<p>それでも、動的サイトは静的ファイル (CSS、JavaScript、静的イメージなど) に対するリクエストをまったく同じ方法で処理するため、静的サイトの機能を理解することはサーバーサイドプログラミングを学ぶときに役立ちます。</p>
+
+<h2 id="動的サイト">動的サイト</h2>
+
+<p><em>動的サイト</em>とは、特定のリクエスト URL とデータに基づいてコンテンツを生成して返すことができる (特定の URL に対して常に同じハードコードファイルを返すのではない) サイトです。製品サイトの例を使用すると、サーバは個々の HTML ファイルではなくデータベースに製品の「データ」を保管します。商品の HTTP <code>GET</code> リクエストを受信すると、サーバは商品 ID を決定し、データベースからデータを取得してから、そのデータを HTML テンプレートに挿入することによって、レスポンス用の HTML ページを作成します。これは静的サイトよりも大きな利点があります。</p>
+
+<p>データベースを使用すると、製品情報を簡単に拡張、変更、および検索可能な方法で効率的に格納できます。</p>
+
+<p>HTML テンプレートを使用すると、HTML 構造の変更が非常に簡単になります。これは 1つの場所、1つのテンプレート内で行う必要があるだけで、潜在的に何千もの静的ページでは行わないためです。</p>
+
+<h3 id="動的リクエストの構造">動的リクエストの構造</h3>
+
+<p>このセクションでは、前回の記事で説明した内容に基づいて、「動的な」HTTP リクエストとレスポンスのサイクルの概要を段階的に説明します。"物事を現実のものにする" ために、コーチが HTML 形式で彼らのチーム名とチームサイズを選択して、彼らの次のゲームのために提案された "最高のラインナップ" を取り戻すことができるスポーツチームマネージャーウェブサイトのコンテキストを使います。</p>
+
+<p>以下の図は、"チームコーチ" Web サイトの主な要素と、コーチが "ベストチーム"リストにアクセスしたときの一連の操作の番号付きラベルを示しています。サイトの一部は <em>Web アプリケーション</em> (これは HTTP リクエストを処理し、HTTP レスポンスを返すサーバーサイドコードを指す方法です)、<em>データベース</em>、これにはプレイヤー、チーム、コーチ、そして彼らの関係についての情報が含まれています、そして <em>HTML テンプレート</em>です。</p>
+
+<p><img alt="This is a diagram of a simple web server with step numbers for each of step of the client-server interaction." src="https://mdn.mozillademos.org/files/13829/Web%20Application%20with%20HTML%20and%20Steps.png" style="height: 584px; width: 1226px;"></p>
+
+<p>コーチがチーム名と選手の数を記入したフォームを送信した後、一連の操作は次のようになります。</p>
+
+<ol>
+ <li>Web ブラウザはリソースのベース URL (<code>/best</code>) を使用し、URL パラメータ (例: <code>/best?team=my_team_name&amp;show=11</code>) または URL パターンの一部 (例: <code>/best/my_team_name/11/</code>) としてチームと選手の番号をエンコードしたものを使用して、サーバへの HTTP <code>GET</code> リクエストを作成します。 <code>GET</code> リクエストが使用されるのは、リクエストがデータをフェッチするだけである (データを変更しない) ためです。</li>
+ <li><em>Web サーバ</em>はリクエストが「動的」であることを検出し、それを処理 (Web サーバは、その構成で定義されたパターンマッチング規則に基づいてさまざまな URL を処理する方法を決定します) のために <em>Web アプリケーション</em>に転送します。</li>
+ <li><em>Web アプリケーション</em>は、リクエストの<em>意図</em>が URL (<code>/best/</code>) に基づいて「最善のチームリスト」を取得することであることを識別し、URL から必要なチーム名とプレーヤーの数を見つけます。その後、<em>Web アプリケーション</em>はデータベースから必要な情報を取得します (<span class="tlid-translation translation" lang="ja"><span title="">どのプレーヤーが「最高」であるかを定義するために追加の「内部」パラメータを使用し、クライアント側の Cookie からログインしたコーチの身元も取得する可能性があります</span></span>)。</li>
+ <li><em>Web アプリケーション</em>は、(<em>データベース</em>からの) データを HTML テンプレート内のプレースホルダに入れることで、HTML ページを動的に作成します。</li>
+ <li><em>Web アプリケーション</em>は、生成された HTML を HTTP ステータスコード 200 ("成功") とともに (<em>Web サーバ</em>経由で) Web ブラウザに返します。HTML が返されるのを妨げるものがあると、<em>Web アプリケーション</em>は別のコードを返します。たとえば、"404" はチームが存在しないことを示します。</li>
+ <li>Web ブラウザは返された HTML の処理を開始し、それが参照する他の CSS または JavaScript ファイルを取得するための個別のリクエストを送信します (手順7を参照)。</li>
+ <li>Web サーバはファイルシステムから静的ファイルをロードして直接ブラウザに返します (これも正しいファイル処理は設定ルールと URL パターンマッチングに基づいています)。</li>
+</ol>
+
+<p>データベース内のレコードを更新する操作も同様に処理されます。データベースの更新と同じですが、ブラウザからの HTTP リクエストは <code>POST</code> リクエストとしてエンコードされるはずです。</p>
+
+<h3 id="他の仕事をする">他の仕事をする</h3>
+
+<p><em>Web アプリケーション</em>の仕事は、HTTP リクエストを受信し、HTTP レスポンスを返すことです。情報を取得または更新するためにデータベースと相互にやり取りすることは非常に一般的な作業ですが、コードは同時に他のことを実行することも、データベースとやり取りしないこともあります。</p>
+
+<p><em>Web アプリケーション</em>が実行する追加のタスクの良い例は、ユーザにメールを送信してサイトへの登録を確認することです。サイトはロギングやその他の操作も実行する可能性があります。</p>
+
+<h3 id="HTML_以外のものを返す">HTML 以外のものを返す</h3>
+
+<p>サーバサイドの Web サイトのコードは、レスポンスに HTML スニペット/ファイルを返す必要はありません。代わりに動的に他の種類のファイル (テキスト、PDF、CSV など) あるいはデータ (JSON、XML など) を作成して返すことができます。</p>
+
+<p>データを動的に更新して自身のコンテンツ ({{glossary("AJAX")}}) を更新できるようにするために Web ブラウザにデータを返すという考えはかなり前からありました。ごく最近では、必要に応じて動的に更新される単一の HTML ファイルを使用して Web サイト全体が作成される「シングルページアプリケーション」が普及しています。このスタイルのアプリケーションを使用して作成された Web サイトは、サーバから Web ブラウザに多くの計算コストをかけます。その結果、Web サイトは (応答性が高いなど) ネイティブアプリケーションのように動作するように見えます。</p>
+
+<h2 id="Web_フレームワークはサーバサイドの_Web_プログラミングを簡素化します">Web フレームワークはサーバサイドの Web プログラミングを簡素化します</h2>
+
+<p>サーバサイド Web フレームワークにより、上記の操作を処理するコードを非常に簡単に書くことができます。</p>
+
+<p>それらが実行する最も重要な操作の1つは、異なるリソース/ページの URL を特定のハンドラ関数にマッピングするための単純なメカニズムを提供することです。これにより、各タイプのリソースに関連付けられているコードを別々にしておくことが容易になります。また、ハンドラ機能を変更することなく、特定の機能を提供するために使用される URL を1か所で変更できるため、メンテナンスの面でもメリットがあります。</p>
+
+<p>たとえば、2つの URL パターンを2つのビュー関数にマップする次の Django (Python) コードを考えてみましょう。最初のパターンは、<code>/best</code> のリソース URL を持つ HTTP リクエストが <code>views</code> モジュールの <code>index()</code> という名前の関数に渡されることを保証します。パターン "<code>/best/junior</code>" を持つリクエストは、代わりに <code>junior()</code> ビュー関数に渡されます。</p>
+
+<pre class="brush: python"># file: best/urls.py
+#
+
+from django.conf.urls import url
+
+from . import views
+
+urlpatterns = [
+    # example: /best/
+    url(r'^$', views.index),
+    # example: /best/junior/
+    url(r'^junior/$', views.junior),
+]</pre>
+
+<div class="note">
+<p><strong>メモ</strong>: <code>url()</code> 関数の最初のパラメータは、「正規表現」(RegEx, または RE) と呼ばれるパターンマッチング手法を使用するため、少し奇妙に見える (たとえば、<code>r'^junior/$'</code>) ことがあります。この時点で正規表現がどのように機能するのかを知る必要はありませんが、(上のハードコードされた値ではなく) URL のパターンと一致させてビュー関数のパラメータとして使用できるという点が異なります。例として、非常に単純な RegExは、「1つの大文字に一致し、その後に4〜7つの小文字を一致させる」と言うかもしれません。</p>
+</div>
+
+<p>Web フレームワークはまた、ビュー関数がデータベースから情報を取得するのを容易にします。データの構造はモデルで定義されています。これは基礎となるデータベースに格納されるフィールドを定義する Python クラスです。"<em>team_type</em>" のフィールドを持つ <em>Team</em> というモデルがある場合は、単純なクエリ構文を使用して特定のタイプを持つすべてのチームを取り戻すことができます。</p>
+
+<p>以下の例では、 "大文字と小文字を区別する" 正確な <code>team_type</code> が "junior" であるすべてのチームのリストを取得します — フォーマットに注意してください。フィールド名 (<code>team_type</code>) の後に二重下線、そして使用する一致のタイプ (この場合は <code>exact</code>) です。他にもたくさんの種類の一致があり、それらをデイジーチェーンでつなげることができます。 順序と返される結果の数も制御できます。</p>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+
+from .models import Team
+
+
+def junior(request):
+    list_teams = Team.objects.filter(team_type__exact="junior")
+    context = {'list': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<p><code>junior()</code> 関数は、ジュニアチームのリストを取得した後、<code>render()</code> 関数を呼び出して、元の <code>HttpRequest</code>、HTML テンプレート、およびテンプレートに含める情報を定義する  "context"  オブジェクトを渡します。<code>render()</code> 関数は、コンテキストと HTML テンプレートを使用して HTML を生成し、それを <code>HttpResponse</code> オブジェクトに返す便利な関数です。</p>
+
+<p>明らかに Web フレームワークは他にも多くのタスクで役に立ちます。次の記事では、さらに多くの利点といくつかの一般的な Web フレームワークの選択について説明します。</p>
+
+<h2 id="まとめ">まとめ</h2>
+
+<p>この時点で、サーバサイドコードが実行しなければならない操作の概要を把握し、サーバーサイド Web フレームワークがこれを容易にする方法をいくつか知っているはずです。</p>
+
+<p>次のモジュールでは、最初のサイトに最適な Web フレームワークを選択する手助けをします。</p>
+
+<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>
+
+<h2 id="このモジュールの記事一覧">このモジュールの記事一覧</h2>
+
+<ul>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Introduction">サーバサイドの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Client-Server_overview">クライアント - サーバの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Web_frameworks">サーバーサイドウェブフレームワーク</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Website_security">Web サイトのセキュリティ</a></li>
+</ul>
diff --git a/files/ja/learn/server-side/first_steps/index.html b/files/ja/learn/server-side/first_steps/index.html
new file mode 100644
index 0000000000..d5acb8040f
--- /dev/null
+++ b/files/ja/learn/server-side/first_steps/index.html
@@ -0,0 +1,47 @@
+---
+title: サーバサイドの Web サイトプログラミングの第一歩
+slug: Learn/Server-side/First_steps
+tags:
+  - CodingScripting
+  - Intro
+  - Landing
+  - ガイド
+  - サーバサイドプログラミング
+  - 初心者
+  - 学習
+translation_of: Learn/Server-side/First_steps
+---
+<div>{{LearnSidebar}}</div>
+
+<p>このモジュールでは、サーバーサイドプログラミングに関するいくつかの基本的な質問、"これは何？"、"クライアントサイドプログラミングとどう違うの？"、"なぜ便利なの？" について答えます。次に、最も人気のあるサーバーサイドの ウェブフレームワークの概要と、最初のサイトを作成するための最適なフレームワークの選択方法に関するガイダンスを提供します。最後に、ウェブサーバーのセキュリティに関する高度な入門記事を提供します。</p>
+
+<h2 id="Prerequisites" name="Prerequisites">前提条件</h2>
+
+<p>このモジュールを開始する前に、サーバーサイドのウェブサイトプログラミングやその他のプログラミングの知識は必要ありません。</p>
+
+<p>しかしながら、"ウェブがどのように動作するか" を理解する必要があります。まず以下のトピックスを読むことをお勧めします:</p>
+
+<ul>
+ <li><a href="/ja/docs/Learn/Common_questions/What_is_a_web_server">ウェブサーバーとは</a></li>
+ <li><a href="/ja/docs/Learn/Common_questions/What_software_do_I_need">ウェブサイトをビルドするために必要なソフトウェアは？</a></li>
+ <li><a href="/ja/docs/Learn/Common_questions/Upload_files_to_a_web_server">ウェブサーバーにファイルをアップロードするには？</a></li>
+</ul>
+
+<p>基本的な事を理解できれば、このセクションを読み進む準備が整います。</p>
+
+<h2 id="Guides" name="Guides">ガイド</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Learn/Server-side/First_steps/Introduction">サーバーサイドの概要</a></dt>
+ <dd>MDN のサーバーサイドプログラミング入門コースにようこそ！この最初の記事では、「それはどんなもの？」、「クライアントサイドプログラミングとはどう違う？」、「なぜ便利なの？」 という質問に答えながら、ハイレベルな視点からサーバーサイドプログラミングを見ていきます。この記事を読めば、サーバーサイドコーディングを行うことで、 ウェブサイトにどんな機能を加えることができるか、理解できるようになります。</dd>
+ <dt><a href="/ja/docs/Learn/Server-side/First_steps/Client-Server_overview">クライアント-サーバーの概要</a></dt>
+ <dd>サーバーサイドプログラミングの目的と潜在的な利点を知ったので、サーバーがブラウザーから "動的リクエスト" を受け取ったときに起こることを詳細に検討します。ほとんどのウェブサイトのサーバーサイドコードは同様の方法でリクエストとレスポンスを処理するので、これは自身のコードの大部分を書くときに何が必要かを理解するのに役立ちます</dd>
+ <dt><a href="/ja/docs/Learn/Server-side/First_steps/Web_frameworks">サーバーサイドウェブフレームワーク</a></dt>
+ <dd>前の記事では、ウェブクライアントとサーバー間の通信、HTTP リクエストとレスポンスの性質、およびウェブブラウザーからのリクエストにレスポンスするためにサーバーサイドウェブアプリケーションが実行する必要があることについて説明しました。この知識をもとに、ウェブフレームワークがどのようにこれらのタスクを単純化できるかを探り、最初のサーバーサイドウェブアプリケーションのためのフレームワークをどのように選択するかを考えてみましょう。</dd>
+ <dt><a href="/ja/docs/Learn/Server-side/First_steps/Website_security">ウェブサイトのセキュリティ</a></dt>
+ <dd>ウェブサイトのセキュリティでは、ウェブサイトのデザインと使用方法のあらゆる面で警戒が必要です。この入門記事ではウェブサイトのセキュリティの第一人者にはなりませんが、脅威がどこから発生するのか、そして最も一般的な攻撃に対して Web アプリケーションを強化するために何ができるのかを理解するのに役立ちます。</dd>
+</dl>
+
+<h2 id="Assessments" name="Assessments">課題</h2>
+
+<p>コードをまだ説明していないため、この "概要" モジュールでは課題はありません。サーバーサイドプログラミングを使用して提供できる機能の種類が何かをよく理解していることを期待しています。また、初めてのウェブサイトを作成するために使用するサーバーサイドの ウェブフレームワークについて決断していることを望みます。</p>
diff --git a/files/ja/learn/server-side/first_steps/introduction/index.html b/files/ja/learn/server-side/first_steps/introduction/index.html
new file mode 100644
index 0000000000..5c269c2d6a
--- /dev/null
+++ b/files/ja/learn/server-side/first_steps/introduction/index.html
@@ -0,0 +1,227 @@
+---
+title: サーバサイドの概要
+slug: Learn/Server-side/First_steps/Introduction
+translation_of: Learn/Server-side/First_steps/Introduction
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary"><span class="seoSummary">MDN のサーバサイドプログラミング入門コースにようこそ！この最初の記事では、「それはどんなもの？」、「クライアントサイドプログラミングとはどう違う？」、「なぜ便利なの？」 という質問に答えながら、ハイレベルな視点からサーバサイドプログラミングを見ていきます。この記事を読めば、サーバサイドコーディングを行うことで、 Web サイトにどんな機能を加えることができるか、理解できるようになります。</span></p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">学習の前提:</th>
+   <td>基本的なコンピュータリテラシーと、Webサーバーとはどんなものかという基礎知識を有していること</td>
+  </tr>
+  <tr>
+   <th scope="row">学習の目的:</th>
+   <td>サーバーサイドプログラミングとは何か、何ができるのか、クライアントサイドプログラミングとどこが違うのか、といった点を理解すること</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>大規模なウエブサイトの多くは、サーバーサイドコードを使うことで、必要に応じた、異なるデータを動的に表示しています。このデータは、サーバーのデータベースから取り出され、クライアントに送られると、（HTMLやJavaScriptで記述された）クライアントサイドコードで表示されます。 </p>
+
+<p>サーバーサイドコードを使う最大の利点は、個々のユーザーにあわせて、ウエブサイトのコンテンツ調整できることでしょう。動的サイトでは、ユーザーの好みや傾向をもとに、より適切なコンテンツを強調表示することができます。また、ユーザーの好みや情報を取り込んで利用することにより、サイトを使いやすくすることもできます。例えば、クレジットカード情報を保管して、次の支払いが簡単に済むようにできます。</p>
+
+<p>加えて、通知や更新情報などを電子メールなどで送ることで、サイトユーザーとの更なるやりとりが可能になります。このような機能を活用することで、ユーザーとの繋がりをより強固なものにできるのです。.</p>
+
+<p>現代のウエブ開発では、サーバーサイドプログラミングを習得することが求められるようになってきました。.</p>
+
+<h2 id="サーバーサイドプログラミングとは何か？">サーバーサイドプログラミングとは何か？</h2>
+
+<p>Webブラウザは、「ハイパー・テキスト・トランスファー・プロトコル ({{glossary("HTTP")}})」を使って<a href="/ja/docs/Learn/Common_questions/What_is_a_web_server">Webサーバー</a>と通信します。Webページのリンクをクリックしたり、入力フォームを送信したり、検索を実行したりすると、ブラウザからサーバーへ<strong>HTTP要求</strong>（Request）が送信されます。</p>
+
+<p>この要求には、関係するデータを指定するURLや、要求するアクションを定めるメソッド（データの取得、削除、送付など）が含まれます。さらに追加情報を含むこともあります。たとえば（<a href="/ja/docs/Web/HTTP/Methods/POST">HTTP POSTメソッド</a>を使ったデータ送付のように）URLのパラメータとして<a href="https://en.wikipedia.org/wiki/Query_string">クエリー文字列</a>を付加したり、{{glossary("Cookie", "クッキー")}}を使ったりします。</p>
+
+<p>Webサーバーはクライアントからの要求を待ちうけ、受信したら、処理を行ってから<strong>HTTP応答</strong>（Response）メッセージをブラウザに返します。このとき応答には、要求の実行が成功したか否かの結果（例えば成功したら"HTTP/1.1 200 OK")を含めます。 </p>
+
+<p>成功したときの応答には、要求されたデータ（例えば、新しいHTMLページやが画像など）が含まれ、ブラウザ上に表示されることになります。</p>
+
+<h3 id="静的サイト">静的サイト</h3>
+
+<p>下図に静的サイトとなるWebサーバーの動作を示します。静的サイトは、要求されたデータに対して、常に一定のコンテンツを返します。新しいページに移るときには、ブラウザから、そのURLを指定したHTTP GET（取得）要求を送ります。</p>
+
+<p>サーバーは要求された文書をファイルシステムから取り出し、<a href="/ja/docs/Web/HTTP/Status#Successful_responses">成功ステータス</a>(通常は"200 OK")と一緒にHTTPレスポンスに入れて送り返します。何らかの原因でファイルが取り出せないときは、エラーステータス(<a href="/ja/docs/Web/HTTP/Status#Client_error_responses">クライアント側エラー</a>あるいは<a href="/ja/docs/Web/HTTP/Status#Server_error_responses">サーバー側エラー</a>)を送り返します。</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png" style="height: 223px; width: 800px;"></p>
+
+<h3 id="動的サイト">動的サイト</h3>
+
+<p>動的ウエブサイトでは、応答に含まれるコンテンツの一部が、必要に応じて「動的に」生成されます。多くの場合、動的ウエブサイトのHTMLページは、データベースから取り出したデータを、HTML雛型の指定された場所に埋め込むことで作られます。これは大量のコンテンツを保存するのに、静的ウエブサイトと比べて、はるかに効率的な方法と言えます。 </p>
+
+<p>動的サイトは、ユーザーから与えられた情報や保存された好みに応じて、同じURL要求であっても異なるデータを返すことができます。また、応答を返すときに他の操作（例えば通知をするなど）を行うこともできます。</p>
+
+<p>動的ウエブサイトを実現するコードの大部分は、サーバー上で実行されます。このコードを作ることを、「<strong>サーバーサイドプログラミング</strong>」（あるいは「<strong>バックエンドスクリプティング</strong>」)と言います。</p>
+
+<p>比較的簡単な動的ウエブサイトの動作を下図に示します。ブラウザがHTTP要求を送ると、サーバーがその要求を処理して、HTTP応答を返すところは、静的ウエブサイトの場合と同じです。</p>
+
+<p>静的データを要求されたときは、静的サイトと同じ動作をします。静的データはファイルとして保存されており、変更されることはありません。例えば、CSS、JavaScript、画像、事前に作成されたPDFファイルなどが、これにあたります。 </p>
+
+<p><img alt="A simplified diagram of a web server that uses server-side programming to get information from a database and construct HTML from templates. This is the same diagram as is in the Client-Server overview." src="https://mdn.mozillademos.org/files/13839/Web%20Application%20with%20HTML%20and%20Steps.png"></p>
+
+<p>動的データを要求されたときは、②の矢印が示すように、（図では「Webアプリケーション」と表示されている）他のサーバーサイドコードに転送されます。そこで要求を解釈し、必要なデータをデータベースから取り出し（③）、HTML雛型に埋め込みます（④）。それを応答としてブラウザに送り返します（⑤と⑥）。 </p>
+
+<div>
+<h2 id="サーバーサイドプログラミングとクライアントサイドプログラミングは同じものか？">サーバーサイドプログラミングとクライアントサイドプログラミングは同じものか？</h2>
+</div>
+
+<p>サーバーサイドプログラミングとクライアントサイドプログラミングを比較してみましょう。両者には明確な差異があります。</p>
+
+<ul>
+ <li>目的も課題も異なる</li>
+ <li>使用するプログラミング言語が異なる（JavaScriptは例外で、両方のプログラミングで使用される）</li>
+ <li>OSも実行環境も異なる</li>
+</ul>
+
+<p>ブラウザで走るコードは<strong>クライアントサイドコード</strong>と呼ばれ、主要な課題は表示されるページの外観や動作を実現することにあります。例えば、どんなユーザーインターフェースを選んでまとめるか、どう配置するか、ナビゲーションをどう支援するか、フォームの入力をどう検証するかといった検討が重要です。いっぽうサーバーサイドプログラミングで重視されるのは、要求に合わせて返すコンテンツをどう選択するかということです。サーバーサイドコードが扱うのは、送付されてきたデータと要求を整合させること、データベースへのデータ登録と取り出し、要求に合致したデータを送り返すことなどです。</p>
+
+<p>クライアントサイドコードに使う言語は、<a href="/ja/docs/Learn/HTML">HTML</a>、<a href="/ja/docs/Learn/CSS">CSS</a>、それに<a href="/ja/docs/Learn/JavaScript">JavaScript</a> です。コードはブラウザ内で実行され、OSへのアクセスはないか、あってもわずかです。ファイルシステムへのアクセスも限定的です</p>
+
+<p>ユーザーが使うブラウザを、Web開発者が選ぶことはできません。クライアントサイドコードを実行するとき、ブラウザの互換性が問題になることがあります。実のところ、ブラウザ間の互換性の差異を克服することが、クライアントサイドプログラミングの大きな課題になっています。</p>
+
+<p>サーバーサイドコードを書くのには、さまざまな言語が使えます。主な例をあげると、PHP、 Python、 Ruby、 C#、NodeJS（JavaScript）などがあります。サーバーサイドコードはサーバーのOSを全面的に利用します。開発者は自分の用途に最適な言語（さらにはバージョンまで）を選ぶことになります。</p>
+
+<p>コードの開発には、<strong>Webフレームワーク </strong>がよく使われます。フレームワークとは、関数やオブジェクト、規則やコード構造などを集めたものです。よく出会う問題を解決したり、開発期間を短縮したり、ある分野で直面する様々な課題を単純化するのに役立てることができます。.</p>
+
+<p>フレームワークは、クライアントサイドコードでもサーバーサイドコードで使われます。しかし、くり返しになりますが、両者には明確な差があり、フレームワークも同じものではありえません。クライアントサイドWebフレームワークが配置と表現力を改善するだけなのに対し、サーバーサイドWebフレームワークはWebサーバーに共通する機能を提供しています。それを使わないとすると、多くの機能を自分で実装する必要があります。例えば、対話セッション、ユーザー認証、データベースへのアクセス、ライブラリの雛型化はフレームワークで実現できます。</p>
+
+<div class="note">
+<p><strong>注</strong>：クライアントサイドフレームワークは、クライアントサイドコードの開発を加速するのによく使われます。いっぽう、すべてのコードを手作りすることも可能です。実際のところ、単純なユーザーインターフェースしか必要としない小規模なWebサイトであれば、手作りの方が短期間で効率的な開発ができます。</p>
+
+<p>これに反して、Webアプリのサーバーサイドコンポーネントの開発は、フレームワークなしでは考えられません。HTTPサーバーのように重要な機能を最初から、例えばPythonで記述するのは、非常に困難なことです。ところがDjangoのようのPython Webフレームワークなら、すぐに使えるし、多くの有用なツールも提供されます。</p>
+</div>
+
+<div>
+<h2 id="サーバーサイドではどんなことができるのか？">サーバーサイドではどんなことができるのか？</h2>
+
+<p>サーバーサイドプログラミングが役に立つのは、ユーザーごとに仕立てられた情報を、効率的に提供できるからです。またそのおかげで、ユーザーにとって使い勝手がよくなるからです。</p>
+</div>
+
+<p>例えばアマゾンのような会社では、サーバーサイドプログラミングによって、商品を検索したり、顧客の好みや過去の購入履歴から商品を勧めたり、すぐに購入できるようにしたりすることができます。</p>
+
+<p>銀行でのサーバーサイドプログラミングでは、口座情報を保管し、それを見たり送金したりするのは、認証の済んだ顧客だけができるようにしています。外にも、Facebook、Twitter、InstagramあるいはWikipdeiaでは、サーバーサイドプログラミングを使って、興味あるコンテンツを取り上げて公開するときのアクセス制限を行っています。</p>
+
+<p>サーバーサイドプログラミングの主な用途とその利点を以下にまとめます。一部は重複しているのが分かると思います。</p>
+
+<h3 id="情報を効率的に保管し、提供する">情報を効率的に保管し、提供する</h3>
+
+<p>アマゾンには何点の商品があるのか、考えたことはありますか？　Facebookへの投稿件数はどうでしょう？　それぞれの商品や投稿ごとに静的なページを作るのは、まったく不可能なことです。</p>
+
+<p>それに代わって、サーバーサイドプログラミングでは、データベースにデータを格納し、動的にページを構成して、HTMLや他の形式（例えばPDFや画像など）のファイルを送り返します。あるいは、{{glossary("JSON")}}や {{glossary("XML")}}などのファイルを送り返すだけで、クライアントサイドの適切なフレームワークに処理を任せることもできます。こうするとサーバーの負荷を軽減し、送るデータ量を削減することができます。</p>
+
+<p>サーバーの送り返す情報は、データベースから取り出したものだけに限りません。他のソフトウエアツールの処理結果だったり、通信サービスが受信したものでも構いません。さらに言うと、ユーザーが使っている機器に合わせて、コンテンツを調整することもできます。</p>
+
+<p>上方がデータベースに保管されているので、他のビジネスシステムが読み取ったり、変更することも可能です。例えば、商品が店舗で売れようと、オンラインで売れようと、一括して在庫を管理できるようになります。</p>
+
+<div class="note">
+<p><strong>実例</strong>：以下の例を見れば、サーバーサイドコードが、情報の効率的な保管と提供に役立つことが実感できるでしょう。</p>
+
+<ol>
+ <li><a href="https://www.amazon.co.jp">アマゾン</a>などの通販サイトを見てください。</li>
+ <li>キーワードを与えて商品を検索します。検索結果はさまざまですが、結果のページの構造は一定です。 </li>
+ <li>検索結果から各商品のページをを比較してみましょう。ページの構造や配置は全く同じことが分かります。商品ごとの情報をデータベースから取り出して、埋め込んでいるからです。</li>
+</ol>
+
+<p>「魚」といった一般的な検索語を使うと、それこそ何百万件もの結果が出てきます。データベースを使うことで、これだけの情報を保管して提供できるのです。ただし、その情報は常に同じ場所に埋め込まれるのです。</p>
+</div>
+
+<h3 id="ユーザーごとに使い勝手を改善する">ユーザーごとに使い勝手を改善する</h3>
+
+<p>サーバーが保管しているクライアントの情報を活用すれば、ユーザーにとって便利なものになり、使い勝手が向上します。例えば、多くの販売サイトではクレジットカード情報を保管して、再入力の手間がかからないようにしています。Googleマップのようなサイトでは、ユーザーの現在位置や保管していた位置を使って、経路情報を提供したり、検索や実際の旅行記録から現地のお勧め場所を表示したりします。</p>
+
+<p>ユーザーの関心を良く分析することで、どこに行きたいかを予想し、それに合わせた応答や通知ができるのです。例えば、以前に行った場所とか、人気の場所を地図上に表示します。</p>
+
+<div class="note">
+<p><strong>実例：</strong><a href="https://maps.google.co.jp/">Googleマップ</a> はユーザーの検索や移動の履歴を保管しています。よく行く場所や検索が多い場所を、優先して表示しています。</p>
+
+<p>Google検索の結果は、以前の検索履歴によって優先づけられています。</p>
+
+<ol>
+ <li> <a href="https:\\google.co.jp">Google検索</a>のページを開いてください。</li>
+ <li> まず「サッカー」を検索します。</li>
+ <li> 今度は、検索語欄に「好きな」と入力して、そのあとに続く語句の候補を見てください。</li>
+</ol>
+
+<p>偶然だろうって？　とんでもない！</p>
+</div>
+
+<h3 id="コンテンツへのアクセスを制限する">コンテンツへのアクセスを制限する</h3>
+
+<p>サーバーサイドプログラミングでは、認証ユーザーのデータへのアクセスを制限し、別のユーザーには許可された情報のみを表示します。</p>
+
+<p>こんな実例があります：</p>
+
+<ul>
+ <li>FacebookのようなSNSでは、自分のデータにはすべてアクセスできますが、友だちには閲覧するかコメントすることしか許していません。ユーザーは誰に閲覧を許すのか、あるいは誰のデータを自分のフィードに引用するのか決めることができます。 許可できることが、ユーザーにとって重要なサービスになっているのです！</li>
+ <li>
+  <p>あなたがいま見ているサイトは、コンテンツへのアクセスを制限しています。記事は誰でも読むことができますが、編集できるのはログインしたユーザーだけです。このページの右上にある「編集」ボタンをクリックしてみてください。あなたがログインしていたら、編集画面が表示されます。ログインしていないなら、ユーザー登録のページに誘導されます。</p>
+ </li>
+</ul>
+
+<div class="note">
+<p><strong>実例：</strong>コンテンツへのアクセスを制限している実例を見てみましょう。銀行のオンラインサイトにアクセスすると、何が見えますか？　あなたの口座にログインすると、どんな情報が出てきますか？　どれが変更できますか？　銀行側にしか変更できない情報は何でしょう？</p>
+</div>
+
+<h3 id="セッションや途中状態の情報を保管する">セッションや途中状態の情報を保管する</h3>
+
+<p>サーバーサイドプログラミングでは、「セッション」を実装できます。これは、現在のサイトユーザーの情報を保管して、それに基づいた応答を返すようにしたものです。</p>
+
+<p>この機能により、ユーザーのログイン履歴を知ることで、電子メールや過去に購入した商品へのリンクを表示できます。オンラインゲームであれば、途中結果を保存して、そこから再開できるできるようになります。</p>
+
+<div class="note">
+<p><strong>実例:</strong>購読型の新聞サイト（例えば<a href="http://www.theage.com.au/">The Age</a>など）を開いて、無料で記事を読んでみてください。数時間か数日読み続けると、購読について説明するページに誘導され、それ以上記事が読めなくなります。これはクッキーで保管されたセッション情報を活用する一例です。（訳注：日本の新聞サイトでは、最初に無料登録を求められますが、そのあとは同じです。）</p>
+</div>
+
+<h3 id="通知やメッセージを送る">通知やメッセージを送る</h3>
+
+<p>サーバーは一般的なお知らせやユーザー毎のお知らせをすることができます。ウエブサイトで表示するだけでなく、電子メールやSNS、インスタントメッセージ、ビデオ会議など、さまざまな通信を使っています。</p>
+
+<p>例をあげてみましょう：</p>
+
+<ul>
+ <li>FacebookやTwitterでは、書き込みがあったときに電子メールやSMSで通知してきます。</li>
+ <li>アマゾンは、過去の買い物や閲覧の履歴から、あなたが興味を持ちそうな商品を、お勧めとして定期的にメールしてきます。</li>
+ <li>Webサーバは、記憶容量の不足や、あやしいアクセスがあったとき、サイト管理者に注意を促すメールを送ってくることがあります。</li>
+</ul>
+
+<div class="note">
+<p><strong>実例:</strong>: いちばんよくある通知の例は、登録確認のお知らせでしょう。興味のある大規模サイト（Google、アマゾンや Instagramなど）ならどこでもいいので、電子メールアドレスを使ってアカウント作ってみてください。すぐに電子メールが届いて、登録完了を知らせてくるか、登録を確認してアカウントを有効にするよう求められます。</p>
+</div>
+
+<h3 id="データを分析する">データを分析する</h3>
+
+<p>ウエブサイトはユーザーに関する大量のデータを収集します。何を検索したか、どんな商品を購入したか、何を推奨したか、そのページにどれだけ長く留まっていたかなどです。サーバーサイドプログラミングでは、このデータを分析することで、応答を改善できるのです。</p>
+
+<p>例えばアマゾンやGoogleは、どちらも以前の検索（や購入）をもとに、商品の宣伝を表示します。</p>
+
+<div class="note">
+<p><strong>実例:</strong> Facebookユーザーの方は、自分のフィードにある投稿を見てください。 記事が、時間順になっていないときがあります。新しい投稿より、「いいね！」が多いもののほうがリストの前の方に現れたりします。</p>
+
+<p>サイトに表示される広告を見てください。その中には、他のサイトで閲覧したものがあります。Facebookがどんなアルゴリズムでコンテンツや広告を処理しているのか不明な点もありますが、あなたの「いいね！」や閲覧履歴をもとにしていることだけは確かです。</p>
+</div>
+
+<h2 id="まとめ">まとめ</h2>
+
+<p>サーバーサイドプログラミングの最初の記事はこれで終わりです。お疲れさまでした。 </p>
+
+<p>ここまでで、サーバーサイドコードはWebサーバー上で実行され、ユーザーにどんな情報を送るか決めるのが主な目的であることを学びました。（ちなみにクライアントサイドコードは、そのデータを配置したり表現したりするのが目的です。）</p>
+
+<p>その有用性は、ウエブサイトが個々のユーザーに合わせた情報を効率的に提供できることと、サーバーサイドで実現できる機能について様々なアイディアが提供できることにあることも、理解いただけたでしょう。</p>
+
+<p>それから、サーバーサイドコードを書く言語は何種類もあり、Webフレームワークを使えば簡単に作れることも、お分かりいただけましたでしょうか。 </p>
+
+<p>次からの記事では、どのフレームワークを選べばよいか考えます。それから、クライアント・サーバー間の相互作用について、もう少し詳しく説明します。</p>
+
+<p>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</p>
+
+<h2 id="このモジュールの記事一覧">このモジュールの記事一覧</h2>
+
+<ul>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Introduction">サーバサイドの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Client-Server_overview">クライアント - サーバの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Web_frameworks">サーバーサイドウェブフレームワーク</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Website_security">Webサイトのセキュリティ</a></li>
+</ul>
diff --git a/files/ja/learn/server-side/first_steps/web_frameworks/index.html b/files/ja/learn/server-side/first_steps/web_frameworks/index.html
new file mode 100644
index 0000000000..5d26d30fa1
--- /dev/null
+++ b/files/ja/learn/server-side/first_steps/web_frameworks/index.html
@@ -0,0 +1,328 @@
+---
+title: サーバーサイドウェブフレームワーク
+slug: Learn/Server-side/First_steps/Web_frameworks
+tags:
+  - Beginner
+  - CodingScripting
+  - Guide
+  - Intro
+  - Learn
+  - Server
+  - Server-side programming
+  - Web frameworks
+translation_of: Learn/Server-side/First_steps/Web_frameworks
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">前の記事では、ウェブクライアントとサーバー間の通信、HTTP リクエストとレスポンスの性質、およびウェブブラウザーからのリクエストにレスポンスするためにサーバーサイドウェブアプリケーションが実行する必要があることについて説明しました。この知識をもとに、ウェブフレームワークがどのようにこれらのタスクを単純化できるかを探り、最初のサーバーサイドウェブアプリケーションのためのフレームワークをどのように選択するかを考えてみましょう。</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">前提条件:</th>
+   <td>基本的なコンピューターリテラシー。サーバー側のコードがHTTP リクエストを処理しレスポンスする方法 (<a href="/ja/docs/Learn/Server-side/First_steps/Client-Server_overview">クライアント - サーバーの概要</a>を参照) についての基本的な知識。</td>
+  </tr>
+  <tr>
+   <th scope="row">目的:</th>
+   <td>ウェブフレームワークがサーバーサイドコードの開発/メンテナンスをどのように簡略化できるかを理解し、自分たちの開発のためのフレームワークの選択を考えさせるため。</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>次のセクションでは、実際のウェブフレームワークから取得したコードフラグメントを使用していくつかのポイントを説明します。今では<strong>すべて</strong>が意味をなさない場合でも、心配しないでください、フレームワーク固有のモジュールコードを通して作業していきますので。</p>
+
+<h2 id="Overview" name="Overview">概要</h2>
+
+<p>サーバーサイドウェブフレームワーク (別名「ウェブアプリケーションフレームワーク」)は、ウェブアプリケーションの作成、保守、および拡張を容易にするソフトウェアフレームワークです。適切なハンドラーへの URL のルーティング、データベースとのやり取り、セッションとユーザー認証のサポート、出力のフォーマット (HTML、JSON、XML など)、ウェブ攻撃に対するセキュリティの向上など、一般的なウェブ開発タスクを簡素化するツールとライブラリーを提供します。</p>
+
+<p>次のセクションでは、ウェブフレームワークによってウェブアプリケーションの開発がどのように容易になるかについて、もう少し詳しく説明します。次に、ウェブフレームワークを選択するために使用できる基準のいくつかを説明し、次にいくつかの選択肢をリストします。</p>
+
+<h2 id="What_can_a_web_framework_do_for_you" name="What_can_a_web_framework_do_for_you">ウェブフレームワークで何ができますか？</h2>
+
+<p>ウェブフレームワークは、一般的なウェブ開発操作を簡素化するためのツールとライブラリーを提供します。サーバーサイドのウェブフレームワークを使う<em>必要</em>はありませんが、使用することを強くお勧めします。それはあなたの人生をずっと楽にするでしょう。</p>
+
+<p>このセクションでは、ウェブフレームワークによって提供されることが多い機能の一部について説明します (必ずしもすべてのフレームワークがこれらの機能のすべてを提供するわけではありません！)。</p>
+
+<h3 id="Work_directly_with_HTTP_requests_and_responses" name="Work_directly_with_HTTP_requests_and_responses">HTTP リクエストとレスポンスを直接操作する</h3>
+
+<p>前回の記事で見たように、ウェブサーバーとブラウザーは HTTP プロトコルを介して通信します。サーバーはブラウザーからの HTTP リクエストを待ってから HTTP レスポンスで情報を返します。ウェブフレームワークを使用すると、これらのリクエストとレスポンスを処理するためのサーバーサイドコードを生成する単純化された構文を作成できます。<span class="tlid-translation translation" lang="ja"><span title="">これは、低レベルのネットワークプリミティブよりも、より簡単な、より高レベルのコードと対話する、より簡単な仕事を持つことを意味します。</span></span></p>
+
+<p>以下の例は、Django (Python) ウェブフレームワークでどのように機能するかを示しています。すべての "view" 関数 (リクエストハンドラー) はリクエスト情報を含む <code>HttpRequest</code> オブジェクトを受け取り、フォーマットされた出力 (この場合は文字列) と共に <code>HttpResponse</code> オブジェクトを返す必要があります。</p>
+
+<pre class="brush: python"># Django view function
+from django.http import HttpResponse
+
+def index(request):
+    # Get an HttpRequest (request)
+    # perform operations using information from the request.
+    # Return HttpResponse
+    return HttpResponse('Output string to return')
+</pre>
+
+<h3 id="Route_requests_to_the_appropriate_handler" name="Route_requests_to_the_appropriate_handler">適切なハンドラーにリクエストをルーティングする</h3>
+
+<p>ほとんどのサイトは、別々の URL からアクセス可能なさまざまなリソースを数多く提供します。これらすべてを 1 つの関数で処理するのは管理が難しいため、ウェブフレームワークは URL パターンを特定のハンドラー関数にマッピングするための単純なメカニズムを提供します。ベースとなるコードを変更することなく特定の機能を提供するために使用される URL を変更できるため、このアプローチにはメンテナンスの面でも利点があります。</p>
+
+<p>フレームワークが異なると、マッピングに異なるメカニズムを使用します。たとえば、Flask (Python) ウェブフレームワークは、デコレーターを使用してビュー関数への経路を追加します。</p>
+
+<pre class="brush: python">@app.route("/")
+def hello():
+    return "Hello World!"</pre>
+
+<p>Django は開発者が URLパターンとビュー関数の間の URLマッピングのリストを定義することを期待しています。</p>
+
+<pre class="brush: python">urlpatterns = [
+    url(r'^$', views.index),
+    # example: /best/myteamname/5/
+    url(r'^(?P&lt;team_name&gt;\w.+?)/(?P&lt;team_number&gt;[0-9]+)/$', views.best),
+]
+</pre>
+
+<h3 id="リクエスト内のデータに簡単にアクセスできるようにする">リクエスト内のデータに簡単にアクセスできるようにする</h3>
+
+<p>データはさまざまな方法で HTTP リクエストにエンコードできます。サーバーからファイルまたはデータを取得するためのHTTP <code>GET</code> リクエストは、URL パラメータまたは URL 構造内で必要なデータをエンコードすることができます。サーバー上のリソースを更新するための HTTP <code>POST</code> リクエストは、代わりに更新情報をリクエストの本文内に「POST データ」として含めます。HTTP リクエストはまた、現在のセッションまたはユーザーに関する情報をクライアント側のクッキーに含めることができます。</p>
+
+<p>ウェブフレームワークは、この情報にアクセスするためのプログラミング言語に適したメカニズムを提供します。<br>
+ たとえば、Django がすべてのビュー関数に渡す <code>HttpRequest</code> オブジェクトには、対象の URL にアクセスするためのメソッドとプロパティ、リクエストの種類 (HTTP <code>GET</code> など)、<code>GET</code> または <code>POST</code> パラメーター、cookie、セッションデータなどが含まれます。Django は URL マッパーで「キャプチャパターン」を定義することで URL の構造にエンコードされた情報を渡すこともできます (上のセクションの最後のコードを見てください)。</p>
+
+<h3 id="データベースアクセスを抽象化および単純化する">データベースアクセスを抽象化および単純化する</h3>
+
+<p>ウェブサイトは、データベースを使用して、ユーザと共有するための情報とユーザに関する情報の両方を保存します。ウェブフレームワークは多くの場合、データベースの読み取り、書き込み、照会、および削除操作を抽象化するデータベース層を提供します。この抽象化層は、オブジェクトリレーショナルマッパー (ORM) と呼ばれます。</p>
+
+<p>ORM を使用することには、2 つのメリットがあります。</p>
+
+<ul>
+ <li>基になるデータベースを使用するコードを必ずしも変更することなく、置き換えることができます。これにより、開発者は使用状況に基づいてさまざまなデータベースの特性を最適化できます。</li>
+ <li>データの基本的な検証はフレームワーク内に実装できます。これにより、データが正しい種類のデータベースフィールドに格納されていること、正しい形式 (メールアドレスなど) であることを確認することが簡単かつ安全になり、いかなる意味でも悪意はありません (クラッカーはデータベースレコードの削除などの悪いことをするために特定の形式のコードを使用することができます)。</li>
+</ul>
+
+<p>たとえば、Django のウェブフレームワークは ORM を提供し、レコードの構造を<em>モデル</em>として定義するために使用されるオブジェクトを参照します。モデルは格納されるべきフィールド<em>タイプ</em>を特定し、それはどの情報を格納することができるかについてのフィールドレベルの検証 (例えば、メールフィールドは有効なメールアドレスのみを許可する) を提供できます。<span class="tlid-translation translation" lang="ja"><span title="">フィールド定義では、最大サイズ、デフォルト値、選択リストのオプション、ドキュメントのヘルプテキスト、フォームのラベルテキストなども指定できます。</span><span title="">コードとは別に変更されるかもしれない設定であるため、モデルは基礎となるデータベースについてのいかなる情報も述べません。</span></span></p>
+
+<p>以下の最初のコードスニペットは、<code>Team</code> オブジェクト用の非常に単純な Django モデルを示しています。これは、チーム名とチームレベルを文字フィールドとして格納し、各レコードに格納する最大文字数を指定します。<code>team_level</code> は選択項目なので、表示される選択項目と保管されるデータの間のマッピング、およびデフォルト値も提供します。</p>
+
+<pre class="brush: python">#best/models.py
+
+from django.db import models
+
+class Team(models.Model):
+    team_name = models.CharField(max_length=40)
+
+    TEAM_LEVELS = (
+        ('U09', 'Under 09s'),
+        ('U10', 'Under 10s'),
+        ('U11, 'Under 11s'),
+        ...  #list our other teams
+    )
+    team_level = models.CharField(max_length=3,choices=TEAM_LEVELS,default='U11')
+</pre>
+
+<p>Django モデルはデータベースを検索するための簡単なクエリ API を提供します。これは、異なる基準 (正確、大文字と小文字を区別しない、より大きいなど) を使用して一度に多数のフィールドに対して一致させることができ、複雑なステートメント (たとえば、"Fr" で始まるチーム名、または "al" で終わるチーム名を持つ U11 チームの検索を指定できます) をサポートすることができます。</p>
+
+<p>2番目のコードスニペットは、すべての U09 チームを表示するための表示機能 (リソースハンドラー) を示しています。この場合、<code>team_level</code> フィールドのテキストが 'U09' であるすべてのレコード (この基準が、2つの下線で区切られたフィールド名と一致タイプを持つ引数、つまり <strong>team_level__exact</strong> として <code>filter()</code> 関数に渡されることに注意してください) をフィルタリングしたいと指定します。</p>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+from .models import Team
+
+def youngest(request):
+    <strong>list_teams = Team.objects.filter(team_level__exact="U09")</strong>
+    context = {'youngest_teams': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<dl>
+</dl>
+
+<h3 id="Rendering_data" name="Rendering_data">データのレンダリング</h3>
+
+<p>ウェブフレームワークは通常テンプレートシステムを提供します。これにより、ページが生成されたときに追加されるデータのプレースホルダーを使用して、出力文書の構造を指定できます。テンプレートは HTML の作成によく使用されますが、他の種類の文書も作成できます。</p>
+
+<p>ウェブフレームワークは多くの場合、{{glossary("JSON")}} や {{glossary("XML")}} など、格納されているデータから他のフォーマットを簡単に生成するためのメカニズムを提供します。</p>
+
+<p>たとえば、Django テンプレートシステムでは、"double-handlebars" 構文 (例えば <code>{</code><code>{ <em>variable_name</em> </code><code>}</code><code>}</code>) を使って変数を指定することができます。これは、ページがレンダリングされるときにビュー関数から渡された値に置き換えられます。テンプレートシステムは式のサポート (構文: <code>{% <em>expression</em> %}</code>) も提供します。これによりテンプレートは、渡されたリスト値を繰り返すような単純な操作を実行できます。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: Jinja2 (Python)、handlebars (JavaScript)、moustache (JavaScript) など、他の多くのテンプレートシステムでも同様の構文が使用されています。</p>
+</div>
+
+<p>以下のコードスニペットはこれがどのように機能するかを示しています。前のセクションの「最年少チーム」の例を続けると、HTML テンプレートにはビューによって <code>youngest_teams</code> というリスト変数が渡されます。HTML スケルトンの内部には、最初に <code>youngest_teams</code> 変数が存在するかどうかを確認し、次に for ループ内でそれを繰り返す式があります。各イテレーションで、テンプレートはチームの <code>team_name</code> 値をリストアイテムに表示します。</p>
+
+<pre class="brush: html">#best/templates/best/index.html
+
+&lt;!DOCTYPE html&gt;
+&lt;html lang="en"&gt;
+&lt;body&gt;
+
+ {% if youngest_teams %}
+    &lt;ul&gt;
+    {% for team in youngest_teams %}
+        &lt;li&gt;\{\{ team.team_name \}\}&lt;/li&gt;
+    {% endfor %}
+    &lt;/ul&gt;
+{% else %}
+    &lt;p&gt;利用できるチームがありません。&lt;/p&gt;
+{% endif %}
+
+&lt;/body&gt;
+&lt;/html&gt;
+</pre>
+
+<h2 id="How_to_select_a_web_framework" name="How_to_select_a_web_framework">ウェブフレームワークの選び方</h2>
+
+<p>使いたいと思うかもしれないほとんどすべてのプログラミング言語には多数のウェブフレームワークが存在します (次のセクションでもっと人気のあるフレームワークの一部をリストします)。選択肢が多すぎると、どのウェブフレームワークが新しいウェブアプリケーションの最適な出発点になるかを判断するのが難しくなります。</p>
+
+<p>決定に影響を与える可能性がある要因の一部は以下のとおりです。</p>
+
+<ul>
+ <li><strong>学ぶ努力:</strong> ウェブフレームワークを学ぶための努力は、基礎となるプログラミング言語、その API の一貫性、その文書の品質、およびそのコミュニティの規模と活動に慣れているかどうかによって異なります。まったくプログラミングの経験がない場合は、Django を検討してください (上記の基準に基づいて学ぶのが最も簡単な方法の1つです)。 すでに特定のウェブフレームワークやプログラミング言語に関する豊富な経験を持っている開発チームの一員であれば、それにこだわるのは理にかなっています。</li>
+ <li><strong>生産性:</strong> 生産性とは、フレームワークに慣れれば新しい機能をどれだけ早く作成できるかを示す尺度であり、コードの作成と保守の両方の作業が含まれます (古い機能が壊れている間は新しい機能を作成できないため)。生産性に影響を与える要因の多くは、「学ぶ努力」の要因と似ています。例えばドキュメント、コミュニティ、プログラミング経験などで、その他の要因としては
+  <ul>
+   <li><em>フレームワークの目的/由来</em>: ウェブフレームワークの中には、特定の種類の問題を解決するために最初に作成されたものもあり、同様の制約を持つウェブアプリケーションを作成するのに優れています。たとえば、Django は新聞のウェブサイトの開発をサポートするために作成されたので、ブログやその他のものを公開するサイトに適しています。それとは対照的に、Flask ははるかに軽量なフレームワークであり、組み込みデバイスで実行されるウェブアプリケーションを作成するのに最適です。</li>
+   <li><em>考え方がある vs ない</em>: 考え方のあるフレームワークは、特定の問題を解決するための推奨される「最善の」方法があるものです。一般的な問題を解決する場合に、考え方のあるフレームワークはより生産的になる傾向がありますが、時々柔軟性が劣ります。</li>
+   <li><em>電池が含まれている か 自分でそれを入手</em>: 一部のウェブフレームワークには、開発者が「デフォルトで」考えうるすべての問題に対処するツール/ライブラリーが含まれています。一方、より軽量なフレームワークには、ウェブ開発者が別々のライブラリーから問題の解決策を選んで解決することがあります (Django は前者の例で、Flask は非常に軽量なフレームワークの例です)。すべてを含むフレームワークは、必要なものがすべて揃っているため、始めるのが簡単なことが多く、それがうまくまとまって文書化されている可能性があります。<br>
+    しかし、より小さなフレームワークに (これから) 必要とするものすべてがあれば、より制約の厳しい環境で実行することができ、学ぶべきことのより小さく簡単なサブセットを持つことになります。</li>
+   <li><em>フレームワークが優れた開発プラクティスを促進するかどうか</em>: たとえば、<a href="/ja/docs/Web/Apps/Fundamentals/Modern_web_app_architecture/MVC_architecture">Model-View-Controller</a> アーキテクチャでコードを論理関数に分割することを推奨するフレームワークは、開発者に期待していないものよりも保守性の高いコードになります。同様に、フレームワーク設計は、コードをテストして再利用することがどれほど簡単かに大きな影響を与える可能性があります。</li>
+  </ul>
+ </li>
+ <li><strong>フレームワーク/プログラミング言語の性能:</strong> Python のような比較的遅いランタイムでも、中規模のサイトを中程度のハードウェアで実行するには「十分」であるため、通常「スピード」が選択の最大の要因になることはありません。他の言語、たとえば C++ または JavaScript のような言語の体感速度の利点は、学習と保守のコストによって相殺される可能性があります。</li>
+ <li><strong>キャッシングサポート:</strong> ウェブサイトがより成功するにつれて、ユーザーがアクセスしたときに受信するリクエストの数に対応できなくなる可能性があります。この時点で、キャッシュのサポートを追加することを検討するかもしれません。キャッシングは、ウェブレスポンスの全部または一部を保存して、後続のリクエストで再計算する必要がないようにするための最適化です。キャッシュされたレスポンスを返すことは、そもそもレスポンスを計算するよりもはるかに高速です。キャッシングは、コード内またはサーバー内 (<a href="https://en.wikipedia.org/wiki/Reverse_proxy">リバースプロキシー</a>を参照) に実装できます。ウェブフレームワークには、キャッシュ可能なコンテンツを定義するさまざまなレベルのサポートがあります。</li>
+ <li><strong>スケーラビリティ:</strong> ウェブサイトが素晴らしく成功すると、キャッシングの利益を使い果たし、さらに<em>垂直なスケーリング</em>の限界に達するでしょう (より強力なハードウェア上であなたのウェブアプリケーションを実行します)。この時点では、<em>水平方向にスケールする</em> (サイトを多数のウェブサーバーやデータベースに分散して負荷を分散する) か、「地理的に」スケールする必要があるかもしれません。選択したウェブフレームワークによって、サイトの規模を拡大するのがいかに簡単になるかが大きく変わります。</li>
+ <li><strong>ウェブセキュリティ:</strong> 一部のウェブフレームワークは、一般的なウェブ攻撃への対処をより適切にサポートします。たとえば Django は HTML テンプレートからのすべてのユーザ入力をサニタイズするので、ユーザが入力した JavaScript は実行できません。他のフレームワークも同様の保護を提供しますが、デフォルトで常に有効になっているわけではありません。</li>
+</ul>
+
+<p>ライセンス、フレームワークが活発に開発されているかどうかなど、他にも多くの要因が考えられます。</p>
+
+<p>プログラミングの完全な初心者であるならば、おそらく「学びやすさ」に基づいてフレームワークを選ぶでしょう。言語自体の「使いやすさ」に加えて、高品質のドキュメント/チュートリアル、および新しいユーザーを支援する活発なコミュニティが最も貴重なリソースです。コースの後半で例を書くために <a href="https://www.djangoproject.com/">Django</a> (Python) と <a href="http://expressjs.com/">Express</a> (Node/JavaScript) を選択しました。これは主にそれらが習得が容易で優れたサポートがあるためです。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: <a href="https://www.djangoproject.com/">Django</a> (Python) と <a href="http://expressjs.com/">Express</a> (Node/JavaScript) のメインウェブサイトに行き、それらのドキュメントとコミュニティを調べてみましょう。</p>
+
+<ol>
+ <li>メインサイトに移動する (上記のリンク先)
+  <ul>
+   <li>Documentation メニューのリンク (Documentation、Guide、API Reference、Getting Started など) をクリックします。</li>
+   <li>URL ルーティング、テンプレート、データベース/モデルの設定方法を説明したトピックはありますか？</li>
+   <li>ドキュメントは明確ですか？</li>
+  </ul>
+ </li>
+ <li>各サイトのメーリングリストに移動します (コミュニティリンクからアクセス可能)。
+  <ul>
+   <li>過去数日間に投稿された質問の数</li>
+   <li>回答はいくつありますか？</li>
+   <li>彼らは活発なコミュニティを持っていますか？</li>
+  </ul>
+ </li>
+</ol>
+</div>
+
+<h2 id="A_few_good_web_frameworks" name="A_few_good_web_frameworks">いくつかの良いウェブフレームワークとは？</h2>
+
+<p>それでは次に、いくつかのサーバーサイドウェブフレームワークについて説明しましょう。</p>
+
+<p>以下のサーバーサイドフレームワークは、執筆時点で入手可能な最も人気のあるものの一部を表しています。オープンソースで、活発に開発されており、熱心なコミュニティがドキュメントを作成し、ディスカッション掲示板でユーザーを支援しています。また、多数の有名ウェブサイトで使用されています。他にも基本的なインターネット検索を使用して見つけられる多くの素晴らしいサーバーサイドフレームワークがあります。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: 説明は (一部) フレームワークウェブサイトから引用しています。</p>
+</div>
+
+<h3 id="Django_Python">Django (Python)</h3>
+
+<p><a href="https://www.djangoproject.com/">Django</a> は、迅速な開発とクリーンで実用的なデザインを促進する高レベルの Python ウェブフレームワークです。</p>
+
+<p>経験豊富な開発者によって構築されており、ウェブ開発における面倒なことの大部分を世話します、そのため、車輪の再発明をする必要なく、アプリの作成に集中できます。無料でオープンソースです。</p>
+
+<p>Django は「バッテリー同梱」という哲学に従い、ほとんどの開発者が「一般的に」実行したいと思うほとんどすべてのことを提供します。すべてが含まれているので、すべて一緒に機能し、一貫した設計原理に従い、そして広範囲かつ最新のドキュメントがあります。また、高速で安全、そして非常にスケーラブルです。Python をベースにしているので、Django のコードは読みやすく、保守も簡単です。</p>
+
+<p>(Django のホームページから) Django を使っている人気のあるサイトには、Disqus、Instagram、Knight Foundation、MacArthur Foundation、Mozilla、National Geographic、Open Knowledge Foundation、Pinterest、Open Stack などがあります。</p>
+
+<h3 id="Flask_Python">Flask (Python)</h3>
+
+<p><a href="http://flask.pocoo.org/">Flask</a> は Python 用のマイクロフレームワークです。</p>
+
+<p>最小構成ですが、Flask は一般的に真面目なウェブサイトを作成することができます。開発サーバーとデバッガーが含まれており、<a href="https://github.com/pallets/jinja">Jinja2</a> テンプレート、セキュアクッキー、<a href="https://en.wikipedia.org/wiki/Unit_testing">ユニットテスト</a>、および <a href="http://www.restapitutorial.com/lessons/restfulresourcenaming.html">RESTful</a> リクエストのディスパッチをサポートしています。良いドキュメントと活発なコミュニティも持っています。</p>
+
+<p>Flask は、特に小規模でリソースに制約のあるシステムでウェブサービスを提供する必要がある開発者 (たとえば、<a href="https://www.raspberrypi.org/">Raspberry Pi</a> でウェブサーバーを実行する、<a href="http://blogtarkin.com/drone-definitions-learning-the-drone-lingo/">Drone コントローラー</a>など) にとって非常に人気があります。</p>
+
+<h3 id="Express_Node.jsJavaScript">Express (Node.js/JavaScript)</h3>
+
+<p><a href="http://expressjs.com/ja/">Express</a> は、<a href="https://nodejs.org/ja/">Node.js</a> 用の高速で、独創的で、柔軟で最小限のウェブフレームワークです (node は JavaScript を実行するためのブラウザーなしの環境です)。ウェブおよびモバイルアプリケーションに堅牢な機能を提供し、便利な HTTP ユーティリティメソッドと<a href="/ja/docs/Glossary/Middleware">ミドルウェア</a>を提供します。</p>
+
+<p>Express はクライアントサイドの JavaScript ウェブプログラマーのサーバーサイド開発への移行が容易である、およびリソース効率が良い (基盤となるノード環境は、新しいウェブリクエストごとに別々のプロセスを生成するのではなく、スレッド内で軽量のマルチタスクを使用します) という部分で、非常に人気があります。</p>
+
+<p>Express は最小限のウェブフレームワークであるため、使用するすべてのコンポーネントが組み込まれているわけではありません (たとえば、データベースへのアクセス、ユーザーおよびセッションのサポートは、独立したライブラリーを通じて提供されます)。多くの優れた独立したコンポーネントがありますが、特定の目的に最適なものを見つけるのが難しい場合があります。</p>
+
+<p><a href="http://feathersjs.com/">Feathers</a>、<a href="https://www.itemsapi.com/">ItemsAPI</a>、<a href="http://keystonejs.com/">KeystoneJS</a>、<a href="http://krakenjs.com/">Kraken</a>、<a href="http://loopback.io/">LoopBack</a>、<a href="http://mean.io/">MEAN</a>、および <a href="http://sailsjs.org/">Sails</a> を含む、多くの一般的なサーバーサイドおよびフルスタックフレームワーク (サーバーサイドフレームワークとクライアントサイドフレームワークの両方を含む) がExpress に基づいています。</p>
+
+<p>Uber、Accenture、IBM などを含む多くの有名企業が Express を使用しています (リストは<a href="http://expressjs.com/en/resources/companies-using-express.html">こちら</a>)。</p>
+
+<h3 id="Ruby_on_Rails_Ruby">Ruby on Rails (Ruby)</h3>
+
+<p><a href="http://rubyonrails.org/">Rails</a> (通常 "Ruby on Rails" と呼ばれる) は、Ruby プログラミング言語用に書かれたウェブフレームワークです。</p>
+
+<p>Rails は Django と非常によく似た設計思想に従っています。 Django と同様に、URL のルーティング、データベースからのデータへのアクセス、テンプレートからの HTML の生成、および {{glossary("JSON")}} または {{glossary("XML")}} としてのデータの書式設定のための標準メカニズムを提供します。それは同様に DRY ("自分で繰り返してはいけない" — 可能であれば一度だけコードを書く)、MVC (model-view-controller) そして他の多くのようなデザインパターンの使用を奨励します。</p>
+
+<p>もちろん、特定の設計上の決定と言語の性質により、多くの違いがあります。</p>
+
+<p>Rails は、<a href="https://basecamp.com/">Basecamp</a>、<a href="https://github.com/">GitHub</a>、<a href="https://shopify.com/">Shopify</a>、<a href="https://airbnb.com/">Airbnb</a>、<a href="https://twitch.tv/">Twitch</a>、<a href="https://soundcloud.com/">SoundCloud</a>、<a href="https://hulu.com/">Hulu</a>、<a href="https://zendesk.com/">Zendesk</a>、<a href="https://square.com/">Square</a>、<a href="https://highrisehq.com/">Highrise</a> などの有名なサイトに使用されています。</p>
+
+<h3 id="Laravel_PHP">Laravel (PHP)</h3>
+
+<p><a href="https://laravel.com/">Laravel</a> は表現力豊かで洗練された構文を持つウェブアプリケーションフレームワークです。Laravel は、次のようなウェブプロジェクトの大部分で使用されている一般的な作業を軽減することで、開発の手間を省くことを試みています。</p>
+
+<ul>
+ <li><a href="https://laravel.com/docs/routing" rel="nofollow">シンプルで高速なルーティングエンジン</a></li>
+ <li><a href="https://laravel.com/docs/container" rel="nofollow">強力な DI コンテナー</a></li>
+ <li><a href="https://laravel.com/docs/session">セッション</a>および<a href="https://laravel.com/docs/cache">キャッシュ</a>ストレージ用の複数のバックエンド</li>
+ <li>表現力豊かで直感的な<a href="https://laravel.com/docs/eloquent">データベース ORM</a></li>
+ <li>データベースにとらわれない<a href="https://laravel.com/docs/migrations">スキーマの移行</a></li>
+ <li><a href="https://laravel.com/docs/queues" rel="nofollow">堅牢なバックグラウンドジョブ処理</a>.</li>
+ <li><a href="https://laravel.com/docs/broadcasting" rel="nofollow">リアルタイムイベントブロードキャスティング</a></li>
+</ul>
+
+<p>Laravel はアクセシビリティに優れながら強力であり、大規模で堅牢なアプリケーションに必要なツールを提供します。</p>
+
+<h3 id="ASP.NET">ASP.NET</h3>
+
+<p><a href="http://www.asp.net/">ASP.NET</a> は、現代のウェブアプリケーションおよびサービスを構築するために Microsoft によって開発されたオープンソースウェブフレームワークです。ASP.NET を使用すると、HTML、CSS、および JavaScript に基づいてウェブサイトを迅速に作成し、何百万ものユーザーが使用できるように拡張し、ウェブ API、データフォーム、リアルタイム通信などのより複雑な機能を簡単に追加できます。</p>
+
+<p>ASP.NET の差別化要因の1つは、<a href="https://en.wikipedia.org/wiki/Common_Language_Runtime">共通言語ランタイム</a> (CLR) 上に構築されていることです。プログラマは、サポートされている .NET 言語 (C#、Visual Basic など) を使用して ASP.NET コードを書くことができます。多くのマイクロソフト製品と同様に、優れたツール (多くの場合無料)、活発な開発者コミュニティ、および適切に記述されたドキュメントから恩恵を受けます。</p>
+
+<p>ASP.NET は、Microsoft、Xbox.com、Stack Overflow、その他多くのユーザーによって使用されています。</p>
+
+<h3 id="Mojolicious_Perl">Mojolicious (Perl)</h3>
+
+<p><a href="http://mojolicious.org/">Mojolicious</a> は、Perl プログラミング言語用の次世代ウェブフレームワークです。</p>
+
+<p>ウェブの初期の頃、<a href="https://metacpan.org/module/CGI">CGI</a> と呼ばれる素晴らしい Perl ライブラリーのおかげで、多くの人が Perl を学びました。それは言語についてあまり知らなくても始めるには十分に単純で、続けるには十分に強力でした。Mojolicious は、最先端のテクノロジを使ってこのアイデアを実現しています。</p>
+
+<p>Mojolicious が提供する機能のいくつかは以下の通りです。<br>
+ <strong>リアルタイムウェブフレームワーク</strong>、つまり単一ファイルのプロトタイプを構造化された MVC ウェブアプリケーションに簡単に拡張できます。RESTful なルート、プラグイン、コマンド、Perl 風のテンプレート、コンテンツネゴシエーション、セッション管理、フォーム検証、テストフレームワーク、静的ファイルサーバー、CGI/<a href="http://plackperl.org">PSGI</a> 検出、ファーストクラス Unicode サポート。IPv6、TLS、SNI、IDNA、HTTP/SOCKS 5 プロキシー、UNIX ドメインソケット、Comet (ロングポーリング)、キープアライブ、コネクションプーリング、タイムアウト、Cookie、マルチパートおよび gzip 圧縮サポートを備えたフルスタックの HTTP および WebSocket クライアント/サーバー実装。CSS セレクターをサポートする JSON および HTML/XML パーサーおよびジェネレーター。隠された魔法のない、とてもきれいで、移植性があり、オブジェクト指向の純粋な Perl API。<br>
+ 長年の経験に基づく新鮮なコード、無料およびオープンソース。</p>
+
+<h3 id="Spring_Boot_Java">Spring Boot (Java)</h3>
+
+<p><a href="https://spring.io/projects/spring-boot">Spring Boot</a> は、<a href="http://spring.io/">Spring</a> が提供している数多くのプロジェクトのうちの 1 つです。<a href="https://www.java.com">Java</a> を使用してサーバーサイドのウェブ開発を行う良い出発点です。</p>
+
+<p><a href="https://www.java.com">Java</a> をベースとした唯一のフレームワークではないことは間違いありませんが、スタンドアローンのプロダクショングレードの Spring ベースのアプリケーションを簡単に実行することができます。これは Spring プラットフォームと他社製ライブラリーの見解に基づいた見方ですが、最小限の手間と設定で始めることができます。</p>
+
+<p>小さな問題にも使用できますが、その強みはクラウドアプローチを使用する大規模アプリケーションを構築することです。通常、複数のアプリケーションが互いに並行して実行され、ユーザーとのインタラクションを提供するものと、バックエンド作業を実行するもの (データベースやその他のサービスへのアクセスなど) のみがあります。ロードバランサーは、冗長性と信頼性を確保したり、ユーザーのリクエストを地理的に処理してレスポンス性を確保したりするのに役立ちます。</p>
+
+<h2 id="まとめ">まとめ</h2>
+
+<p>この記事では、ウェブフレームワークによって、サーバーサイドコードの開発と保守が容易になることを示しました。また、いくつかの一般的なフレームワークの概要とウェブアプリケーションフレームワークの選択基準についても説明しました。これで、少なくとも自身のサーバーサイド開発用のウェブフレームワークを選択する方法についてのアイデアが得られました。 そうでなくても心配しないでください。コースの後半で Django と Express に関する詳細なチュートリアルを提供して、ウェブフレームワークを実際に使用する経験をいくつか提供します。</p>
+
+<p>このモジュールの次の記事では、方向を少し変えてウェブセキュリティについて考えます。</p>
+
+<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</p>
+
+<h2 id="このモジュールの記事一覧">このモジュールの記事一覧</h2>
+
+<ul>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Introduction">サーバサイドの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Client-Server_overview">クライアント - サーバの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Web_frameworks">サーバーサイドウェブフレームワーク</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Website_security">Webサイトのセキュリティ</a></li>
+</ul>
diff --git a/files/ja/learn/server-side/first_steps/website_security/index.html b/files/ja/learn/server-side/first_steps/website_security/index.html
new file mode 100644
index 0000000000..59c9a7dbf7
--- /dev/null
+++ b/files/ja/learn/server-side/first_steps/website_security/index.html
@@ -0,0 +1,181 @@
+---
+title: Web サイトのセキュリティ
+slug: Learn/Server-side/First_steps/Website_security
+tags:
+  - CodingScripting
+  - Web サイトセキュリティ
+  - Web セキュリティ
+  - イントロダクション
+  - ガイド
+  - サーバサイドプログラミング
+  - セキュリテイ
+  - 初心者
+  - 学習
+translation_of: Learn/Server-side/First_steps/Website_security
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">ウェブサイトのセキュリティでは、ウェブサイトのデザインと使用方法のあらゆる面で警戒が必要です。この入門記事だけではウェブサイトのセキュリティの第一人者にはなれませんが、脅威がどこから発生するのか、そして最も一般的な攻撃に対してウェブアプリケーションを強化するために何ができるのかを理解するのに役立ちます。</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">前提条件:</th>
+   <td>基本的なコンピューターリテラシー</td>
+  </tr>
+  <tr>
+   <th scope="row">目標:</th>
+   <td>ウェブアプリケーションのセキュリティに対する最も一般的な脅威と、サイトがハッキングされるリスクを減らすためにできることを理解する。</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="ウェブサイトのセキュリティとは">ウェブサイトのセキュリティとは?</h2>
+
+<p>インターネットは危険な場所です。定期的に、サービス拒否攻撃によってウェブサイトが利用できなくなったり、自分のホームページに変更された (多くの場合有害な) 情報を表示したりすることがあります。その他の注目を集める事例では、何百万ものパスワード、メールアドレス、およびクレジットカードの詳細がパブリックドメインに漏洩し、ウェブサイトの利用者を個人的な当惑と経済的リスクの両方にさらしています。</p>
+
+<p>ウェブサイトのセキュリティの目的は、これらの (または任意の) 種類の攻撃を防ぐことです。ウェブサイトセキュリティのより正式な定義は、<em>許可されていないアクセス、使用、改変、破壊、または混乱からウェブサイトを保護することです</em>。</p>
+
+<p>効果的なウェブサイトセキュリティでは、ウェブアプリケーション、Web サーバーの設定、パスワードの作成と更新に関するポリシー、およびクライアント側のコードなど、ウェブサイト全体にわたる設計作業が必要です。すべて不吉に聞こえるかもしれませんが、サーバーサイド Web フレームワークを使用している場合、多くの一般的な攻撃に対して「デフォルトで」堅牢でよく考え抜かれた防御メカニズムがほぼ確実に有効になります。HTTPS を有効にするなど、他の攻撃は Web サーバーの設定を通じて軽減できます。最後に、明らかな間違いを犯したかどうかを確認するのに役立つ、公開されている脆弱性スキャナツールがあります。</p>
+
+<p>この記事の残りの部分では、いくつかの一般的な脅威と、サイトを保護するために実行できる簡単な手順の詳細について説明します。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: これは導入トピックであり、ウェブサイトのセキュリティについて考え始めるのに役立つように設計されていますが、網羅的なものではありません。</p>
+</div>
+
+<h2 id="ウェブサイトのセキュリティ上の脅威">ウェブサイトのセキュリティ上の脅威</h2>
+
+<p>このセクションでは、最も一般的なウェブサイトの脅威をいくつか紹介し、それらがどのように軽減されるのかを示します。お読みになったところでは、ウェブアプリケーションがブラウザーから来るデータについて信頼しているか、または十分に妄想的ではない場合に、脅威が最も効果的であることに注意してください。</p>
+
+<h3 id="クロスサイトスクリプティング_XSS">クロスサイトスクリプティング (XSS)</h3>
+
+<p>XSS は、攻撃者がウェブサイト<em>を通じて</em>他のユーザーのブラウザーにクライアントサイドのスクリプトを挿入することを可能にする一連の攻撃を表すために使用される用語です。注入されたコードはサイトからブラウザーに送信されるため、コードは<em>信頼されており</em>、ユーザーのサイト認証 Cookie を攻撃者に送信するなどのことが可能です。攻撃者が Cookie を持っていると、あたかもユーザーであるかのようにサイトにログインし、クレジットカードの詳細へのアクセス、連絡先の詳細の表示、パスワードの変更など、ユーザーができることなら何でもできます。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: XSS 脆弱性は、他のどの種類のセキュリティの脅威よりも歴史的に一般的です。</p>
+</div>
+
+<p>XSS 脆弱性は、サイトが挿入されたスクリプトをブラウザーに返す方法に基づいて、<em>反映型</em>と<em>永続型</em>に分けられます。</p>
+
+<ul>
+ <li>サーバーに渡されたユーザーコンテンツが<em>ただちに</em>返され、<em>変更されず</em>にブラウザー側で表示される場合に、XSS の脆弱性が反映されます。元のユーザーコンテンツのスクリプトはすべて、新しいページが読み込まれたときに実行されます。たとえば、検索語が URL パラメータとしてエンコードされ、これらの語が結果と一緒に表示されるサイト検索機能を考えてみましょう。攻撃者は悪意のあるスクリプトをパラメータとして含む検索リンク (例: <code>http://mysite.com?q=beer&lt;script%20src="http://evilsite.com/tricky.js"&gt;&lt;/script&gt;</code>) を作成し、それを別のユーザーにメールで送信することができます。ターゲットユーザーがこの「関連リンク」をクリックすると、検索結果が表示されたときにスクリプトが実行されます。すでに説明したように、これにより攻撃者はターゲットユーザーとしてサイトに入るために必要なすべての情報が得られ、ユーザーとして購入したり、連絡先情報を共有したりする可能性があります。</li>
+ <li>
+  <p>悪意のあるスクリプトがウェブサイトに保存され、その後、他のユーザーが知らないうちに実行されるように変更されないまま再表示されると、<em>永続的な</em> XSS の脆弱性が発生します。たとえば、変更されていない HTML を含むコメントを受け付けるディスカッション掲示板は、攻撃者からの悪意のあるスクリプトが埋め込まれる可能性があります。コメントが表示されると、スクリプトが実行され、ユーザーのアカウントにアクセスするために必要な情報が攻撃者に送信される可能性があります。この種の攻撃は非常に有名で強力です。攻撃者は被害者と直接関わりさえしないかもしれないからです。</p>
+ </li>
+</ul>
+
+<p><code>POST</code> または <code>GET</code> リクエストからのデータが XSS の脆弱性の最も一般的な原因ですが、ブラウザーによって表示される Cookie データやアップロードされて表示されるユーザーファイルなど、ブラウザーからのデータはすべて潜在的に脆弱です。</p>
+
+<p>XSS の脆弱性に対する最善の防御策は、コードを実行するための命令を含む可能性があるマークアップを削除または無効にすることです。HTML の場合、これには <code>&lt;script&gt;</code>、<code>&lt;object&gt;</code>、<code>&lt;embed&gt;</code>、および <code>&lt;link&gt;</code> などの要素が含まれます。</p>
+
+<div>
+<p>スクリプトを実行したり、サーバーコードの実行に影響を与えたりすることができないようにユーザーデータを変更するプロセスは、入力サニタイズと呼ばれます。多くのウェブフレームワークは、デフォルトで HTML フォームからのユーザー入力を自動的にサニタイズします。</p>
+</div>
+
+<h3 id="SQL_インジェクション">SQL インジェクション</h3>
+
+<p>SQL インジェクションの脆弱性により、悪意のあるユーザーはデータベース上で任意の SQL コードを実行することができ、ユーザーの許可に関係なくデータへのアクセス、変更、削除ができます。インジェクション攻撃が成功すると、ID を偽装したり、管理者権限を持つ新しい ID を作成したり、サーバー上のすべてのデータにアクセスしたり、データを破壊または変更して使用できなくなる可能性があります。</p>
+
+<div>
+<p>SQL インジェクションの種類には、エラーベースの SQL インジェクション、ブールエラーに基づく SQL インジェクション、および時間ベースの SQL インジェクションがあります。</p>
+</div>
+
+<p>ベースとなる SQL ステートメントに渡されるユーザー入力がステートメントの意味を変更する可能性がある場合に、この脆弱性が存在します。たとえば、次のコードは、HTML フォームから提供された特定の名前 (<code>userName</code>) を持つすべてのユーザーを一覧表示することを目的としています。</p>
+
+<pre class="brush: sql">statement = "SELECT * FROM users WHERE name = '" + <strong>userName</strong> + "';"</pre>
+
+<p>ユーザーが実名を指定した場合、そのステートメントは意図したとおりに機能します。ただし、悪意のあるユーザーは <code>userName</code> に太字のテキストを指定するだけで、この SQL ステートメントの動作を次の例の新しいステートメントに完全に変更する可能性があります。</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't</strong>';
+</pre>
+
+<p>変更された文は、<code>users</code> テーブルを削除し、<code>userinfo</code> テーブルからすべてのデータを選択する (すべてのユーザーの情報を表示する) 有効な SQL 文を作成します。これは、挿入されたテキストの最初の部分 (<code>a';</code>) が元の文を完成させるために機能します。</p>
+
+<p>この種の攻撃を回避するには、SQL クエリに渡されるユーザーデータがクエリの性質を変更できないようにする必要があります。これを行う 1 つの方法は、SQL で特別な意味を持つユーザー入力内のすべての文字を<a href="https://en.wikipedia.org/wiki/Escape_character">エスケープ</a>することです。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: SQL ステートメントは、<strong>'</strong> 文字を文字列リテラルの開始と終了として扱います。この文字の前に円記号を入れる (<strong>\'</strong>) ことで、シンボルをエスケープし、代わりにそれを文字 (文字列の一部) として扱うように SQL に指示します。</p>
+</div>
+
+<p>次の文では、<strong>'</strong> 文字をエスケープします。SQL は名前を太字の文字列全体として解釈します (これは非常に奇妙な名前ですが、有害ではありません)。</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t'</strong>;
+</pre>
+
+<p>ウェブフレームワークはしばしばあなたのためにエスケープする文字の面倒を見るでしょう。たとえば、Django はクエリセット (モデルクエリ) に渡されたユーザーデータが確実にエスケープされるようにします。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: このセクションは<a href="https://en.wikipedia.org/wiki/SQL_injection">ここウィキペディア</a>の情報に大きく依存しています。</p>
+</div>
+
+<h3 id="クロスサイトリクエストフォージェリ_CSRF">クロスサイトリクエストフォージェリ (CSRF)</h3>
+
+<p>CSRF 攻撃は、悪意のあるユーザーが他のユーザーの資格情報を使用して、そのユーザーの知らないうちに同意なしでアクションを実行することを可能にします。</p>
+
+<p>この種の攻撃は、例で最もよく説明されています。John は、特定のサイトでログインユーザーがアカウント名と金額を含む HTTP <code>POST</code> リクエストを使用して特定のアカウントに送金できることを知っている悪意のあるユーザーです。John は、自分の銀行の詳細と金額を隠しフィールドとして含むフォームを作成し、それを他のサイトユーザーにメールで送信します ([送信] ボタンは [早く金持ちになる] サイトへのリンクとして偽装)。</p>
+
+<p>ユーザーが[送信]ボタンをクリックすると、トランザクションの詳細と、サイトに関連付けられているブラウザーが要求したクライアント側の Cookie を含む HTTP <code>POST</code> リクエストがサーバーに送信されます (リクエストに関連サイトの Cookie を追加するのは通常のブラウザーの動作です)。サーバーは Cookie をチェックし、それらを使用してユーザーがログインしていてトランザクションを実行する権限を持っているかどうかを判断します。</p>
+
+<p>その結果、取引サイトにログインしている間に [送信] ボタンをクリックしたすべてのユーザーが取引を行うことになります。John は金持ちになります。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: ここでのトリックは、John がユーザーの cookie (またはアクセス資格情報) にアクセスする必要がないことです。ユーザーのブラウザーはこの情報を保存し、関連するサーバーへのすべてのリクエストに自動的に含めます。</p>
+</div>
+
+<p>この種の攻撃を防ぐ 1 つの方法は、サーバーが <code>POST</code> リクエストにユーザー固有のサイト生成のシークレット情報を含めることを要求することです。転送に使用されるウェブフォームを送信するときに、シークレットがサーバーによって提供されます。この方法では、サーバーからユーザーに提供されているシークレットを知っている必要があるため、John は独自のフォームを作成できません。たとえ彼がシークレットを見つけて特定のユーザーのためにフォームを作成したとしても、彼はもはやその同じフォームを使用してすべてのユーザーを攻撃することはできないでしょう。</p>
+
+<p>ウェブフレームワークには、そのような CSRF 防止メカニズムが含まれていることがよくあります。</p>
+
+<h3 id="その他の脅威">その他の脅威</h3>
+
+<p>その他の一般的な攻撃/脆弱性は次のとおりです。</p>
+
+<ul>
+ <li><a href="https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0">クリックジャッキング</a>。この攻撃では、悪意のあるユーザーが目に見えるトップレベルサイトのクリックをハイジャックし、その下にある非表示のページにルーティングします。このテクニックは、例えば、合法的な銀行のサイトを表示するが、攻撃者によって制御された目に見えない {{htmlelement("iframe")}} にログイン資格情報をキャプチャするために使用されるかもしれません。クリックジャックを使用して、表示されているサイト上のボタンをユーザーにクリックさせることもできますが、実際にはまったく違うボタンを無意識にクリックしています。対応策として、サイトに他のサイトの iframe を埋め込まれないように適切な HTTP ヘッダを設定することで防ぐことができます。</li>
+ <li><a href="/ja/docs/Glossary/Distributed_Denial_of_Service">Denial of Service</a> (DoS)。DoS は通常、正当なユーザーのサイトへのアクセスが妨害されるように、偽のリクエストで対象のサイトをあふれさせることで達成されます。リクエストは単純で多数あり得るか、または個々に大量のリソースを消費し得る (例えば、遅い読み取りまたは大きなファイルのアップロード) ものです。DoS 防御は通常、正当なメッセージの通過を許可しながら、「悪い」トラフィックを識別してブロックすることによって機能します。これらの防御は通常、ウェブサーバーの前または内部にあります (これらはウェブアプリケーション自体の一部ではありません)。</li>
+ <li><a href="https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%83%88%E3%83%A9%E3%83%90%E3%83%BC%E3%82%B5%E3%83%AB">ディレクトリートラバーサル</a> (ファイルと開示)。この攻撃では、悪意のあるユーザーが ウェブサーバーのファイルシステムのアクセスできない部分にアクセスを試みます。この脆弱性は、ユーザーがファイルシステムのナビゲーション文字を含むファイル名 (たとえば<code>../../</code>) を渡すことができる場合に発生します。解決策は、使用する前に入力をサニタイズすることです。</li>
+ <li><a href="https://en.wikipedia.org/wiki/File_inclusion_vulnerability">ファイルインクルード</a>。この攻撃では、ユーザーはサーバーに渡されたデータを表示または実行するための「意図しない」ファイルを指定することができます。このファイルがロードされると、ウェブサーバーまたはクライアントサイドで実行される (XSS 攻撃につながる) 可能性があります。解決策は、使用する前に入力をサニタイズすることです。</li>
+ <li><a href="https://www.owasp.org/index.php/Command_Injection">コマンドインジェクション</a>。コマンドインジェクション攻撃により、悪意のあるユーザーはホスト OS で任意のシステムコマンドを実行することができます。解決策は、システムコールで使用される前にユーザー入力をサニタイズすることです。</li>
+</ul>
+
+<p>ウェブサイトのセキュリティ脅威の包括的な一覧については、<a href="https://en.wikipedia.org/wiki/Category:Web_security_exploits">Category: Web security exploits</a> (Wikipedia) および <a href="https://www.owasp.org/index.php/Category:Attack">Category: Attack</a> (Open Web Application Security Project) を参照してください。</p>
+
+<h2 id="いくつかの重要なメッセージ">いくつかの重要なメッセージ</h2>
+
+<p>ウェブアプリケーションがブラウザーからのデータを信頼している場合、前のセクションのセキュリティ上の悪用のほとんどすべてが成功します。ウェブサイトのセキュリティを向上させるために他に何をしても、ブラウザーから表示される前、SQL クエリで使用される前、または OS やファイルシステムの呼び出しに渡される前に、すべてのユーザー発信データをサニタイズする必要があります。</p>
+
+<div class="warning">
+<p>重要:ウェブサイトのセキュリティについて学ぶことができる最も重要な教訓は、<strong>ブラウザーからのデータを決して信用しない</strong>ことです。これには <code>GET</code> リクエスト、<code>POST</code> リクエスト、HTTP ヘッダと Cookie、およびユーザーがアップロードしたファイルの URL パラメータのデータが含まれますが、これらに限りません。すべての受信データを常にチェックしてサニタイズしてください。常に最悪の事態を想定してください。</p>
+</div>
+
+<p>あなたが取れる他の具体的な対策はいくつかあります：</p>
+
+<ul>
+ <li>より効果的なパスワード管理を使用してください。定期的に変更される強力なパスワードを推奨します。パスワードに加えてユーザーが別の認証コード (通常は、自分の電話に送信される SMS のコードなど、ユーザーだけが所有する物理的なハードウェアを介して配信されるもの) を入力する必要があるように、サイトの 2要素認証を検討してください。</li>
+ <li>HTTPS および HTTP Strict Transport Security (HSTS) を使用するように Web サーバーを設定します。HTTPS は、クライアントとサーバー間で送信されるデータを暗号化します。これにより、ログイン認証情報、Cookie、<code>POST</code> リクエストデータ、およびヘッダ情報が攻撃者に容易に利用されないようになります。</li>
+ <li>最も一般的な脅威 (<a href="https://owasp.org/www-project-top-ten/">現在の OWASP リストはこちら</a>) を追跡し、最も一般的な脆弱性を最初に解決します。</li>
+ <li>サイトで自動セキュリティテストを実行するには、<a href="https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools">脆弱性スキャンツール</a>を使用してください。後で、非常に成功したウェブサイトも <a href="https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/">Mozilla がここでしているような</a>バグ報奨金を提供することによってバグが見つかるかもしれません。</li>
+ <li>必要なデータのみを保存して表示してください。たとえば、ユーザーがクレジットカード情報などの機密情報を保存する必要がある場合は、ユーザーが識別できるだけの十分なカード番号を表示してください。そうすれば攻撃者がそれをコピーして別のサイトで使用することはできません。現時点で最も一般的なパターンは、クレジットカード番号の最後の 4桁だけを表示することです。</li>
+</ul>
+
+<p>ウェブフレームワークは、より一般的な脆弱性の多くを軽減するのに役立ちます。</p>
+
+<h2 id="まとめ">まとめ</h2>
+
+<p>この記事では、ウェブセキュリティの概念と、ウェブサイトが保護しようとする一般的な脅威について説明しました。最も重要なことは、ウェブアプリケーションはウェブブラウザーからのデータを信頼できないということです。すべてのユーザーデータは、表示する前にサニタイズするか、SQL クエリやファイルシステムコールで使用する必要があります。</p>
+
+<p>この記事で、<a href="/ja/docs/Learn/Server-side/First_steps">モジュール</a>の終わりに来ました。サーバーサイドのウェブサイトプログラミングの最初のステップをカバーしました。これらの基本概念を学んで楽しんでいただければ幸いです。これでウェブフレームワークを選択してプログラミングを開始する準備が整いました。</p>
+
+<p>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>
+
+<h2 id="このモジュールの記事一覧">このモジュールの記事一覧</h2>
+
+<ul>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Introduction">サーバーサイドの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Client-Server_overview">クライアント - サーバーの概要</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Web_frameworks">サーバーサイドウェブフレームワーク</a></li>
+ <li><a href="/ja/docs/Learn/Server-side/First_steps/Website_security">ウェブサイトのセキュリティ</a></li>
+</ul>