【HTML実践】複数のプルダウンが連動するやつ Part1

皆さんこんにちは！SoLA2です。この前、製品管理システムを作っていたのですが、その時にエリアを選択するための入力フォームで親子関係を作る部分で迷ったのでメモしておきます。

今回の記事はかなりエンジニア向けになっております。次回以降の記事で、初心者向けに各ソースの解説をした記事を投稿しますので、わからなかった方は少々お待ちください。

親プルダウンと子プルダウン

皆さんも、親プルダウンが選択されると、子プルダウンの選択肢が変化するようなフォームを見たことがあると思います。具体例でだと親プルダウンに「地方」、子プルダウンに「都道府県」などがそれにあたると思います。以下のページの地域選択フォームがそれにあたります。
www.manpowerjobnet.com

下記の仕様概要にあるようなフォームをつくる為にはどうしたらよいか、ちょっと作り方を調べてみました。よく見かけるフォームなので、すぐ見つかるかと思ったのですが、割と苦労しました。

サーバ側の処理

こういった類のものでまず判断するべきは、サーバ処理が入るかどうかだと思います。選択肢が都道府県くらいの数であれば、画面ロード時にすべて取得してしまい、JSだけで切替処理をするのもアリだと思います。

ですが、割とそういった方法を採用せずに、選択された地域の値を一旦サーバ側に渡して、地域に紐づく都道府県の一覧を取得後、フロントエンドに反映する方式を紹介している解説サイトが多かった印象です。

確かに、地域と都道府県の紐づきをDBに持たせてしまえば、異動や組織改編などで情報が変わった時、スクリプトの改修が必要ないのでお客様に説明しやすいのかもしれませんね。

非同期処理

サーバ側の処理があるということは、何らかの形で処理をサーバ側に持っていく必要があるということです。今回はajaxを使って非同期処理でサーバ側に処理を投げてしまいましょう。

ちなみに、何でもかんでも非同期処理に回してしまうと、後で処理の整合性を取るのが難しくなり、後悔することもあるので気を付けましょう。

仕様概要

プルダウンが3つ存在する

• プルダウン①
• プルダウン②
• プルダウン③

プルダウンはそれぞれ親子関係にある

• プルダウン①の子がプルダウン②
• プルダウン②の子がプルダウン③

親の値が変更されると子が以下のように状態変化する

• 子の値が初期化
• 親の値が初期値の場合、子は選択不可

各プルダウンの値はDBから取得する

• プルダウン①：地域（東北とか関東とか）
• プルダウン②：都道府県（青森とか東京とか）
• プルダウン③：店舗（青森支店とか東京支店とか）

コーディング

フロントエンド

HTMLは下記の通りです。関係ないクラスは極力減らしましたが、一部bootstrapのクラスが残っています。

<div class="form-group row">
	<label> 登録店舗<span class="attention">*</span>:</label>
	<div class="col-sm-3">
		<select id="area_cd_1" name="area_cd_1">
			<option value="-1">エリアを選択</option>
			<?= $mcode->getSelecterList('area_cd_1', $app->preSetValues); ?>
		</select>
	</div>
	<div class="col-sm-3">
		<select id="area_cd_2" name="area_cd_2" <?= vSelectionDisabled('area_cd_1', $app->preSetValues); ?>>
			<option value="-1">エリアを絞込み</option>
			<?= $areaLink->getValue($app->preSetValues); ?>
		</select>
	</div>
	<div class="col-sm-3">
		<select id="area_cd_3" name="area_cd_3" <?= vSelectionDisabled('area_cd_2', $app->preSetValues); ?>>
			<option value="-1">店舗名</option>
			<?= $shop->getShopInArea2($app->preSetValues); ?>
		</select>
	</div>
</div>

getSelecterList、getValue、getShopInArea2は初期値と初期選択肢をセットするためのメソッドです。本件の本質とは異なりますので内容は割愛します。

またCSSに関しても、本件の仕様を満たすために必須な記述はないので省きます。

JSは下記のとおりです。jQueryとajaxを利用しています。

//エリアの入力フォーム制御（プルダウン）
$(function () {
    //エリア1が変更された場合、それに紐づく都道府県プルダウンの選択肢を変更する
    $('#area_cd_1').on('change', function () {
        var area_cd_1_val = $(this).val();

        $.post('../_area_cd_1_updated_ajax.php', {
            mode: 'area_cd_1',
            area_cd_1: area_cd_1_val
        }, function (data) {
            //selectタグ（子） の option値 を一旦削除
            $('#area_cd_2 option').remove();
            
            //_area_cd_1_updated_ajax.php から戻って来た data の値をそれそれ optionタグ として生成し、
            // #area_cd_2 に optionタグ を追加する
            $('#area_cd_2').append($('<option>').text('エリアを絞込み').attr('value', -1));

            if (data.length == 0) {
                $('#area_cd_2').prop('disabled', true);
            } else {
                $('#area_cd_2').prop('disabled', false);
            }

            for (var area in data) {
                $('#area_cd_2').append($('<option>').text(data[area]['area_val_2']).attr('value', data[area]['area_cd_2']));
            }

            $('#area_cd_2').trigger('change');
        });
    });

    //エリア2（都道府県）が変更された場合、それに紐づく店舗プルダウンの選択肢を変更する
    $('#area_cd_2').on('change', function () {
        if($('#area_cd_3').length) {
            var area_cd_2_val = $('#area_cd_2').val();

            $.post('../_area_cd_2_updated_ajax.php', {
                mode: 'area_cd_2',
                area_cd_2: area_cd_2_val
            }, function (data) {
                //selectタグ（子） の option値 を一旦削除
                $('#area_cd_3 option').remove();
                
                //_area_cd_2_updated_ajax.php から戻って来た data の値をそれそれ optionタグ として生成し、
                // #area_cd_3 に optionタグ を追加する
                $('#area_cd_3').append($('<option>').text('店舗名').attr('value', -1));

                if (data.length == 0) {
                    $('#area_cd_3').prop('disabled', true);
                } else {
                    $('#area_cd_3').prop('disabled', false);
                }

                for (var area in data) {
                    $('#area_cd_3').append($('<option>').text(data[area]['shop_name']).attr('value', data[area]['id']));
                }
            });
        }
    });
});

バックエンド

バックエンド側の処理は渡された親の値を元に子の選択肢を生成ところがメインになります。

_area_cd_1_updated_ajax.php

<?php

//直接のページ遷移を阻止
$request = isset($_SERVER['HTTP_X_REQUESTED_WITH']) ? strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) : '';
if($request !== 'xmlhttprequest') exit;

if ($_SERVER['REQUEST_METHOD'] === 'POST') {

	try {
		$res = _area_cd_1();
		header('Content-Type: application/json');
		echo json_encode($res);
		exit;
	} catch (Exception $e) {
		header($_SERVER['SERVER_PROTOCOL'] . ' サーバ内処理エラーが発生しました。（500）', true, 500);
		echo $e->getMessage();
		exit;
	}
}

/**
 * 指定したエリアコード1に紐づくエリアコード2の情報を配列で返す
 * @return array: 指定したエリアコード1に紐づくエリアコード2の情報
 * @throws \Exception :エリアコード1の情報が存在しなかった場合に発生する
 */
function _area_cd_1()
{
	if (!isset($_POST['area_cd_1'])) {
		throw new \Exception('エリアコード1の情報がセットされていません。');
	}
	$areaLinks = new \MyApp\Model\AreaLink();

	return $areaLinks->getAjaxValue($_POST['area_cd_1']);
}

_area_cd_2_updated_ajax.php

<?php

//直接のページ遷移を阻止
$request = isset($_SERVER['HTTP_X_REQUESTED_WITH']) ? strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) : '';
if($request !== 'xmlhttprequest') exit;

if ($_SERVER['REQUEST_METHOD'] === 'POST') {

	try {
		$res = _area_cd_2();
		header('Content-Type: application/json');
		echo json_encode($res);
		exit;
	} catch (Exception $e) {
		header($_SERVER['SERVER_PROTOCOL'] . ' サーバ内処理エラーが発生しました。（500）', true, 500);
		echo $e->getMessage();
		exit;
	}
}

/**
 * 指定したエリアコード2に紐づく店舗情報を配列で返す
 * @return array: 指定したエリアコード2に紐づく店舗の情報
 * @throws \Exception :エリアコード2の情報が存在しなかった場合に発生する
 */
function _area_cd_2(){
	if (!isset($_POST['area_cd_2'])) {
		throw new \Exception('エリアコード2の情報がセットされていません。');
	}
	$shops = new \MyApp\Model\Shop();

	return $shops->getAjaxShopInArea2($_POST['area_cd_2']);
}

getAjaxValueや、getAjaxShopInArea2はここでは定義しておりませんが、基本的にDBからHTML形式で値を生成するメソッドです。本件の本質とは異なりますので、割愛します。

ソースを貼ったら文字数がとんでもないことになってしまったので、それぞれの解説は以降の記事で実施しようと思います。

まとめ

プルダウンの選択肢が多すぎたとしても、致命的な問題になるわけではありませんが、やはりUIにこだわるのであれば、選択肢の数はスクロールバーが表示されない程度に抑えたいものですね。

何より、お客様からこの形式のプルダウンをご要望頂くことが多いので、覚えておいて損はないと思います。

今回はこのソースを見て足りないところを補完できるエンジニアに向けて、先に全体像をお伝えいたしました。次回以降の記事で、初心者の方にもわかるようにソースを解説していきたいと思います。

ではでは

専門用語少なめ！GIT入門-コミットとステージング【基礎知識シリーズ】

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第5回目です。今回も引き続きGit入門ということで、コミットについて解説していきます。さあみなさんも結果にコミットしていきましょう。

コミットとは

あのRIZAPのCMでおなじみのフレーズをきっかけに「コミット」という言葉を知った方も多いかも知れません。Gitの世界で「コミット」とは、バージョン毎の記録を意味します。なので「結果にコミットする」をGit風に言うならば、「筋トレをして新しいバージョンの体を作りましょう」でしょうか（笑

コミットの中身

Gitでコミットはバージョン毎の記録であることは前述しました。では、何が記録されているのでしょうか。大きく分けて3つの要素が記録されています。

• 変更情報（いつ、だれが、何を変更したか）
• 備考（変更者のメッセージ）
• システム管理用情報（リビジョン番号と、前バージョンのリビジョン番号）

コミットというとなんだか大それた感じがしますが、中身は割とシンプルですね。リビジョン番号というのは、コミット版のマイナンバーみたいなものです。実際には番号ではありませんが、すべてのコミットの中でひとつしか存在しないという点では同じです。

余談ですが、リビジョン番号は1から始まる連番ではなく、コミット内容のハッシュ値で管理されています。ただ一意の番号を振りたいだけなら連番にすればいいところ、なぜこのような面倒な仕様にしたのか。実はこれにはわけがあります。

前回の記事でリポジトリにはローカルリポジトリとグローバルリポジトリがあることを説明したと思います。バージョン管理を複数のリポジトリで行うことを分散型と呼びますが、分散型のようにリポジトリが複数存在すると困ることがあるのです。

リビジョン番号をそれぞれのローカルリポジトリで連番にしてしまうと、変更内容をグローバルリポジトリに反映する時に、リビジョン番号が重複してしまう可能性が出てくるのです。そのためこのような面倒な文字の羅列でリビジョン番号を一意にしています。

コミットするまでの流れ

実はGitの場合はファイル変更してからコミットするまでに、もう一段階手順が存在します。省略することも可能ですが、便利ですので積極的に使っていきましょう。

インデックスへの追加

実は、バージョン管理下にあるファイルを変更してもそれを直ちにコミット対象のファイルとして認識することはありません。変更したファイルの中からコミット対象となるファイルを選択する必要があります。この選択する行為をインデックスに追加（ステージング状態にする）と言います。

バージョン管理をしたことが無いと、なぜこのような冗長的な行為をする必要があるのかピンと来ない方もいるかも知れません。実はバージョン管理のしやすさを考慮すると、この中間地点が非常に便利（というより必須）に感じるようになります。

そもそもバージョン管理をする理由は、バックアップを取っておいて必要なときにすばやく前のバージョンへ戻すためでした。であれば、バージョン毎に「どのタイミングで取得したバックアップなのか」は明確であるべきで、更に言うと「戻りたいタイミングでバックアップをとっておく」べきなのです。

バージョンとはコミットのことでしたね？つまり「Aという修正」と「Bという修正」をして、それらを一括でコミットしてしまうと、戻れる地点が「AとBを修正する前」だけになってしまいます。AとBに関連性があればそれでいいのですが、全く別物だった場合は都合が悪いですね。

そこで、一旦「Aという修正」の該当箇所のみをインデックスに追加してからコミットし、その後「Bという修正」の該当箇所をインデックスに追加してコミットすることで、戻れる地点を「AとBを修正する前」と「Bを修正する前」に増やすことができるようになります。

コミットの粒度に関しては多すぎても少なすぎても良くありません。塩梅についてはある程度の目安はあるにしても、経験を積んで理解するしかありません。いずれにしろ確実に言えることは、インデックス（ステージング）という概念はGitにおいて非常に重要であるということです。

まとめ

今回はGitのコミットについて学びました。これで一人でバージョン管理する分には必要な知識が揃いました。次回は実際にファイルのバージョン管理をしていく流れをスクリーンショットを交えて紹介していきます。

ではまた。

専門用語少なめ！GIT入門-バージョン管理の必要性とリポジトリ【基礎知識シリーズ】

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第4回目です。今回のテーマはGit入門ということで、バージョン管理の必要性とリポジトリについて紹介します。Gitというと少し堅苦しくて使いたくないな・・・と感じるかも知れませんが、「ファイルのバージョン管理をしてくれる仕組み」と考えれば少しは興味が沸くのではないでしょうか？

バージョン管理とは

チームで開発をしたことのあるエンジニアであれば必要性について説明するまでも無いですが、実は「個人で開発をしている方」にとってもバージョン管理システムは有用なものです。

個人で開発していると、ファイル名の末尾に文言を加えたりしてバックアップを取った経験はありませんか？これは手軽にファイルをバックアップできる手段ですが、末尾に追加できる内容は精々バックアップ日時程度ではないでしょうか。

それに比べ、バージョン管理システムであれば、ほぼ無制限で備考を記録しておくことができます。さらに手動でバックアップしていると、どうしても「バックアップのし忘れ」という悲劇が起こり得ます。

そこで！ファイルの変更を自動で監視してくれるバージョン管理システムの出番というわけです。

Gitとは

Gitは、リモートで大規模なシステムを開発する際、「効率的にファイルのバージョン管理をするため」に生み出されました。具体的にバージョン毎に何を管理しているのかを下記に示します。

• いつの更新なのか
• 誰が更新したのか
• どのファイルを更新したのか
• ファイルのどこを更新したのか
• どのような変更内容なのか
• どのような備考を残したのか

上記の情報を参考に、現行のファイルを過去のバージョンに戻すことができます。要はファイル管理に必要な情報を効率的に残してくれて、必要に応じてバックアップ時点にファイルを巻き戻してくれるシステムなのです。

リポジトリ

上述したように、バージョン管理には様々な情報を保存しておく必要があります。その保存場所の事をリポジトリと呼びます。

基本的にバージョン管理する対象は何かのプロジェクト（ファイル群）であるケースがほとんどですので、プロジェクトのルートディレクトリ（一番上の階層に存在するフォルダ）配下をリポジトリで管理するように設定することで、プロジェクトのバージョン管理をします。

ローカルリポジトリとリモートリポジトリ

リポジトリには作業PC内のリポジトリと、オンライン上で管理しているリポジトリの2種類が存在します。

ローカルリポジトリ

ローカルリポジトリは実際に作業をするリポジトリを指し、自分専用のリポジトリです。基本的には作業PC内で管理します。

リモートリポジトリ

リモートリポジトリはネットワーク上で管理します。それぞれの作業は、ローカルリポジトリで行い、最終的な内容をリモートリポジトリに反映します。この場合リモートリポジトリの内容が常に正であるという考えが基本です。

このようなバージョン管理の方法を分散型と呼びます。分散型のバージョン管理を採用することでリモートで複数人が開発する際に、ファイルが前のバージョンに戻ってしまったり、バージョンが無造作に増えてしまうリスクを軽減できます。

SVNとの違い

バージョン管理システムでGitと同じくらいよく耳にするのがSVNです。Gitとの大きな違いはリポジトリの持ち方です。上記で説明したとおり、Gitはリポジトリを複数生成してバージョンを管理します。それに対してSVNはリポジトリ1つでバージョン管理する仕組みです。

そのため、チームで開発する場合はGitを使ったほうが無難です。個人の場合はどちらでもいいと思いますが、Gitを使っておけばソース公開するときも何かと便利ですし、私はGitをおすすめします。

まとめ

いかがだったでしょうか。今回はバージョン管理の必要性と、リポジトリについて学びました。バージョン管理は開発をする上で手間となるため適当にされがちですが、ファイルに何か会った場合に被害を最小限に押さえてくれる保険のようなものです。

次回は変更内容をローカルリポジトリへ反映する「コミット」について解説していきます。

ではまた。

【HTML基礎】SEのゆかりさんが淡々と解説する動画【floatと回り込み】

概要

皆さんこんにちは、SoLA2です。

現場でバリバリ働いているエンジニアのアナタ！bootstrapのグリッドシステムを利用してしまえばfloatなんていらんわ！とか思って、floatの知識が曖昧なまま、誤魔化したりしてませんかー？・・・何を隠そう私がそう思ってました。

なので戒めの意味も込めてfloatに関する記事を書こうと思います。今回は基礎知識シリーズ番外編です。毎回堅苦しいのもどうかと思ったので、今回は動画にしてみました。動画で見にくいコード部分は記事に載せておきます。

floatと回り込み

サンプルコード

HTML

• float-sample.html

<!DOCTYPE html>

<html>
    <head>
        <meta charset="utf-8">
        <title>サンプル</title>
        <link rel="stylesheet" href="css/style.css">
    </head>
    <body>
        <header>
            ヘッダ
        </header>

        <div class="wrapper">
            <div class="mainContent">
                メイン
            </div>
            <div class="sideBar">
                サイドバー
            </div>    
        </div>

        <footer>
            フッター
        </footer>
    </body>
</html>

CSS

• style.css

body {
    color: white;
}

header {
    height: 50px;
    background-color: red;
    margin-bottom: 20px;
}

.wrapper::after {
    content:'ここに挿入されてます。';
    color: black;
    clear: both;
    display: block;
}

.mainContent {
    float: left;
    height: 100px;
    width: 60%;
    background-color: green;
}

.sideBar {
    float: right;
    height: 100px;
    width: 30%;
    background-color: blue;
}

footer {
    height: 50px;
    background-color: black;
    margin-top: 20px;
}

まとめ

いかがだったでしょうか。今回はHTMLでややっこしいfloatについて学びました。最近はbootstrapなど便利なものがあるので、こういった基本的な事は忘れがちになってしまいますが、時々そういったものが使えないシーンに出くわすこともありますので、そういったときに恥を欠かないように抑えておきましょう！

ではまた。

専門用語少なめ！HTTP入門-URLとURI【基礎知識シリーズ】

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第3回目です。今回のテーマはURLとURIについてです。実を言うとシステム開発をする段階では、あまりURIやURLの知識が必要になることは無いのですが、見積り作成や、要件定義の段階でインフラエンジニアと相談する際に、抑えておきたい部分ではあります。

URIとURLについて

URIとURLってすごく似ていますね。実はURNなんてものもあったりします。これらの違いについて説明しようと思ったのですが、わかりやすい例えをしている記事があったのでそちらを御覧ください。
qiita.com

上記の記事にもあるように、URIはURLやURNの総称です。URLは対象の場所を一意に特定する、いわばインターネット上の住所ということですね。そのため、URLの事をアドレスなんて呼んだりもします。

URLを構成する要素

WEBアプリケーションを開発する上で、URLを構成する要素について理解する事は、必須となります。インターネットには無数のURLが所狭しと存在している訳ですが、これらURLは無秩序な文字の羅列というわけではありません。実際にいくつかURLを並べてみましょう。

• GoogleのURL：https://www.google.co.jp/
• このブログのURL：https://www.sola2-tech.com/
• 著者TwitterのURL：https://twitter.com/_SoLA2

いくつか共通点が見えてくると思います。まずURLの先頭から「://」までの区間ですが、上記の例では、全て「HTTPS」となっていますね。この部分はプロトコル（規約）を意味してます。ですので、上記の例にはありませんが、HTTPS以外にも、HTTPであったり、FTPなんかが存在します。

次に「://」以降最初の「.」まではホスト名を表しております。ホスト名は省略されることもあります。上記の例でいうと「著者TwitterのURL」はホスト名が省略されております。そして最初の「.」から「:」までの部分をドメインと呼んでおります。

・・・あれ？上記の例には「:」なんてないぞ！と思われるかも知れません。これはその次の要素であるポートが省略されているためです。ちなみにURLの最初の要素はプロトコルを表していることは前述しましたが、プロトコルが決まると、一般的に使用するポートも決まります。

この一般的に使用するポートの事を、ウェルノウンポートと呼びます。URI上で、ポートが省略されている場合は、ウェルノウンポートを使っていることを意味しています。

ポートは「:」から次の「/」までです。「/」以降はパスと呼ばれる部分で、サーバ内のどこに対象が配置されているのかを表しています。このパスで指定した場所にファイルが存在しない場合は404 NotFoundが返ってくるというわけです。

ドメイン名

ドメイン名は、インターネット上の場所を特定するためのものです。場所を特定するための名前なので、ドメイン名はインターネット上で一意の値となる必要があります。そのためドメインを新たに取得する場合は、ドメインを管理している組織に申請する必要があります。

余談ですが、ドメインは「.」を堺に右に行く程、範囲が大きくなります。一番右側はトップレベルドメイン（.comや.jpなど）と呼ばれます。日本の住所は最初に書く方が、範囲も大きいので違和感があるかも知れませんが、海外の場合は、右に行くほど範囲が大きくなるので、それが踏襲されたのでしょう。

ポート番号

サーバにもタワーマンションのように、多数のコンピュータがサーバの配下に存在するケースがあります。その場合、ポートはマンションの玄関を番号で表したものと言えるでしょう。通信はどの玄関から出てきて、どの玄関へ入るのかをポート番号で管理しています。

WEBアプリケーションの開発では基本的にウェルノウンポートを使うので、あまりポート番号を意識する必要はありません。とはいえ、セキュリティを考慮して一般とは違ったポートを使用する際や、ローカル開発環境でテストをする際に時々必要になる概念なので覚えておきましょう。

まとめ

いかがだったでしょうか。今回はURLとURI（とは言ってもほとんどURL）について学びました。少し細かい内容で、若干実践的ではなかったですが、インフラエンジニアと会話する際には、知らないとお話にならない内容なので、是非抑えておきましょう。

ではまた。

専門用語少なめ！HTTP入門-リクエストとレスポンス【基礎知識シリーズ】

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第2回目です。今回は、HTTPリクエストやHTTPレスポンスについて解説します。ふとした時にヘッダ情報を扱わなければならなくなり、苦戦するエンジニアも多いはず！そこで今回はそんなとき困らないように、実践で必要となる部分に的を絞って解説していきたいと思います。

HTTPリクエストとHTTPレスポンス

前回の記事でお伝えしたとおり、「ブラウザ（クライアント）」が「サーバ」に対して接続を要求するときに出すものをリクエスト、正確にはHTTPリクエストといいます。また、そのHTTPリクエストに対して「サーバ」が返すものをHTTPレスポンスと呼びます。

HTTPリクエストやHTTPレスポンスは、ぱっと見文字の羅列なのでとっつきにくいと思います。なので3つの領域に分けてしまいましょう。

HTTPリクエストのフォーマット

HTTPリクエストを3つの領域に分けると下記の3領域になります。

• リクエスト・ライン（最初の1行）
• メッセージ・ヘッダ（最初の1行を除く空白行より前の部分）
• メッセージ・ボディ（空白行より後の部分）

最初の1行に記述されている部分は、リクエスト・ラインと呼ばれ、ここを見れば大まかに、どういったリクエストなのかを判断することができます。HTTPリクエストのリクエスト・ラインを更に細かく分けると、「メソッド」「URI」「HTTPバージョン」の3要素に分けることができます。

メソッドの種類

「メソッド」は「サーバにどのような動作をして欲しいのか」を伝えるための要素です。例えば、典型的なパターンとして「フォームに入力したデータを指定したURIのプログラムに渡す」といった動作がそれに該当します。

メソッドにはいくつか種類が存在しますが、数が多いので全ての種類を覚えるのではなく、代表的な4つを覚えておきましょう。この4つはRESTと呼ばれる設計思想を満たすアプリケーションを開発する際に必要となるものです。

• GET：URIで指定した要素を取得します。
• POST：URIで指定した場所に登録します。
• PUT：URIで指定した要素を更新します。
• DELETE：URIで指定した要素を削除します。

余談ですが筆者も、AWSの「Lmbda」と「API Gateway」を使ってサーバレスのアプリケーションを開発しようとした時、GETとPOSTしか知らなくて戸惑った記憶があります。サーバレスを選択肢のひとつにできると、お客様の要件と合致した場合は、コストを抑えることができるため提案の幅が広がります。

URIとURL

「URI」でなんぞ？「URL」に似てるなって思った方、鋭いですね。実際に「URL」は「URI」のことでもあります。正確には「URI」は「URL」よりも広義の意味で使われますが、現状は「URL」＝「URI」と認識しておいて問題ありません。詳しくは次回の記事で解説します。

HTTPレスポンスのフォーマット

HTTPレスポンスを3つの領域に分けると下記の3領域になります。

• ステータス・ライン（最初の1行）
• メッセージ・ヘッダ（最初の1行を除く空白行より前の部分）
• メッセージ・ボディ（空白行より後の部分）

最初の1行に記述されている部分は、ステータス・ラインと呼ばれています。HTTPレスポンスのステータス・ラインを更に細かく分けると、「HTTPバージョン」「ステータス・コード」「レスポンス・フレーズ」の3要素に分けることができます。

「ステータス・コード」と「レスポンス・フレーズ」

名前だけだとピンとこない人も、次の文言には見覚えがあるのではないでしょうか？

「404 Not Found」

指定したURLでページが見つからなかったときに、よく表示されるあれですね。実はこの文言こそが、「ステータス・コード」と「レスポンス・フレーズ」なのです。細かい話をすると、404が「ステータス・コード」で、Not Foundが「レスポンス・フレーズ」です。

システムの保守を担当しているエンジニアであれば、障害対応でお馴染みの「ステータス・コード」ですが、種類が非常に多いので、すべて覚える必要はありません。ですが、百の位がステータスの大まかな意味を表していることくらいは理解しておきましょう。

• 100番代：単なる情報を返しています
• 200番代：成功した旨を返しています
• 300番代：さらなる処理を要求しています
• 400番代：リクエストに誤りがあった旨を返しています
• 500番代：リクエストの処理に失敗した旨を返しています

まとめ

いかがだったでしょうか。今回はHTTPリクエストとHTTPレスポンスについて学びました。これらの知識はネットワークエンジニアのみならず、デバックや障害対応をするエンジニアであれば知っていて損はない領域でしょう。

いざ必要になってから調べ始めると存外時間がかかるものです。真のエンジニアとして活躍したいのであれば、日頃からこういった知識に触れて、最低限の基礎知識は習得しておいたほうが良いと思います。

次回は、今回もちらっと登場したURIについてもう少し踏みこんだ内容を解説していきたいと思います。
ではまた。

専門用語少なめ！HTTP入門-プロトコルの概要について【基礎知識シリーズ】

概要

皆さんこんにちは、SoLA2です。今回から初心者でも、現場でバリバリ働いているプロのエンジニアであっても、意外に忘れがちな、ITに関する基礎知識について掲載していきたいと思います。

記念すべき第一回は、「HTTP」について！「HTTP」とか「HTTPS」ってインターネットをしている人なら、よく目にする単語だと思います。でも意外にこの意味がわかる人って意外に少ないのではないでしょうか。

HTTPってなに？

そもそもHTTPはある言葉の省略したものです。どのような言葉だかご存知でしょうか。

「Hypertext Transfer Protocol」

ですね。知ってる！って方も多いかと思います。直訳すると、「ハイパーテキストをやり取りするための決まりごと」といった感じでしょうか。「ハイパーテキスト」ってなんやね！とツッコミを入れたくなる方もいるかも知れません。

ハイパーテキストも略語です。正式には「Hypertext Markup Language」と呼びます。つまり「HTML」のことです。今皆さんが見ているこのWEBサイトは基本的に「HTML」と呼ばれるフォーマットで記述されています。

話は戻りますが、この「HTML」をやり取りするための決まりごとが「HTTP」という訳です。

安全を考慮した通信

皆さんはインターネットで買い物をすることはあるでしょうか。私はよくAmazonを利用しています。本当に便利ですよね。家にいながら大体のものは手に入れることができる。素晴らしい。

ですが便利な半面、「不特定多数がアクセスするインターネット上に、個人情報を入力するのは一抹の不安がある」という方もいらっしゃるかと思います。そこで、そういった方でも安心して利用するための技術が、暗号化です。

「HTTP」に暗号化の技術を採用したものが「HTTPS」と呼ばれます。この「S」は「Secure」の略です。「HTTPS」はデータを暗号化してやり取りするので、第三者に読み取られにくいというメリットがあります。今後WEBサイトやWEBアプリケーションを開発するのであれば、基本的に「HTTPS」を使うようにしましょう。

プロトコル（決まりごと）

プロトコルという言葉は、エンジニアには馴染み深い言葉ですが、そうでない人からすると「ハイパーテキスト」に次ぐミステリーワードですね。日本語訳は「規約（決めごとや、約束事）」を意味します。

こういった規約が存在するのには理由があります。コンピュータは人間のように、曖昧なものを判断することが苦手です。加えてインターネットは不特定多数の人がアクセスするので、皆が無秩序にやり取りすると、いくら性能の良いコンピュータであっても混乱の元になります。

そこで皆が同じルールに則ってやり取りすることで、そこで交わされるデータのフォーマットに一貫性が生まれるため、曖昧なものを判断することが苦手なコンピュータでも混乱しないような工夫が「プロトコル（規約）」なのです。

サーバとクライアント

インターネットにアクセスする場合、一般的にそのユーザが操作する「ブラウザ（クライアント）」からホームページを公開している「サーバ」に対してリクエストを投げます。このように、インターネットと一口に言っても様々な機構から構成されています。

HTTPにおいて重要になる機構は、「サーバ」と「クライアント」です。この両者間でプロトコル（規約）に則ってデータをやり取りすることになります。

HTTPリクエストとHTTPレスポンス

上記で少し話題に出ましたが、「ブラウザ（クライアント）」が「サーバ」に対して接続を要求するときに出すものをリクエスト、正確にはHTTPリクエストといいます。また、そのHTTPリクエストに対して「サーバ」が返すものをHTTPレスポンスと呼びます。

まとめ

いかがだったでしょうか。今回は少し初級者向きの内容だったかも知れませんが、最近は優秀なフレームワークが存在するため、現役のエンジニアであってもこういった基礎知識を忘れてしまいがちです。

HTTPはWEBサイトやWEBアプリケーションを開発するための一番基礎となる知識ですので、時々立ち止まって気分転換がてら復習してみるのも良いかも知れません。

次回はHTTPリクエストやHTTPレスポンスについてもう少し踏みこんだ内容を載せていきます。
ではまた。