はじめに
Web業界に転職して、そろそろ1年が経過します。
今まで勉強した知識にどの程度抜け漏れがあるのか確認のために、今更ながら「プロになるためのWeb技術入門」を読みました。
改めて理解が促進した箇所、新たな発見があった箇所を列挙します。
なお、私の頭脳のワークスペースの都合上、書籍の前半部しかまとめられてないです。
リソースの位置を示すURL
URLの仕組みは、なんとなく使っているので、改めて復習しました。
URLは、ブラウザにアドレスバーに打ち込む文字列です。
インターネット上のコンテンツを一意に指定するための仕組みが「URL(Uniform Rsource Locator)なのです。
日本語に訳すと「統一資源位置子（とういつしげんいちし）」となります。
http :// /www.littleforest.jp / webtext/index.html スキーム ホスト名 パス名
パーセントエンコード
https://www.test/index.php?name=%E3%83%86%E3%82%B9%E3%83%88
インターネットサーフィンをしてるとURLに「%」が混じることがありますよね
URLは全角文字は使用できないので、ブラウザ側がサーバーでも読み取れる文字にエンコードしてくれます。
これが「パーセントエンコード」です。
スキーム
そもそもhttpsとは何なんか最初のうちはよくわかりませんでした。
スキームは、リソースを取得するための方法を表します。Webアプリケーションにえいては、ほとんどの場合「http」となります
スキーム名 説明 https 暗号化されたhttp通信を表すスキーム mailto 電子メールの宛先を表すスキーム ftp FTPプロトコルによる入手を表すスキーム file ファイルシステム中のファイルやディレクトリを参照するためのスキーム
URLとURIの違い
他のWeb技術の基礎本を読んでいるときに、URLという単語という単語がほぼ登場せず、代わりにURIという単語で使われていることがあります。
URLとURIの違いはなんでしょうか。
URIは、URLをより拡張した概念として、URI(Uniform Resource Idenrifier)が考え出されたのです。
URIとは、URLに加えて「URN(Uniform Rsource Name)」を合わせたものを指します。
URNはインターネット上に存在する名前を一意に識別するために用意されたものです。
URLの場合は、ホストが移動すると移動先のURLを知らないとアクセスできなくなります。
URNは、このようなリソースの移動に関しての問題を解決するために、インターネット上に存在するリソースに対しては統一的な名前を決めようと考え出されたものです。
例えば、「nrn:itif:rfc:2616」は、HTTP1.1のRFCに対するURNです。この文書が物理的にどのような位置に存在しようと、同じURNで指し示すことができるというわけです。
現状ではURNはあまり利用されておらず、実質的にはURIもURLもほぼ同じ意味で扱われています。
混乱の元はURIとURLもほぼ同様の意味で使用されているため、なぜ2種類もの呼び方があるのか理解できないことです。
このように背景を理解してしまえば、理解しやすいですね。
Webベンチャーで働いている人に、あまり馴染みのないサーブレット、JSP
PHPやRubyでアプリケーションを作っていると、Javaに対してあまり馴染みがありません。
しかしJavaもエンタープライズでのWeb開発で使用されている言語、歴史的変遷だけでも知っておくのがいいかと思いました。
サーブレットの誕生
Webが普及しCGIが一般的になると、新たな問題が生まれました。
1つはPerlの仕様による問題、もう一つは多数のリクエストによるアクセス負荷の増大する問題です。
Java自体はWebアプリケーションのために開発された言語ではありません。しかし、Webアプリケーションは当時企業に置けるシステム開発でも主流になりつつありました。
そこで、JavaEE(Java Enterprise Edition)の一部として「サーブレット(Servlet)」というWebアプリケーション開発をサポートするため目の機能が供給されるようになったのです。
サーブレットはJavaで作られたHTMLなどのWebコンテンツを生成するためのプログラムのことで、CGIを経由して起動されるPerlやC言語のJava版に相当します。
サーブレットは基本的にCGIと同じ考え方ですが、コンテンツを生成する言語がJavaであり、オブジェクト志向のサポートによって大規模アプリケーションの開発に向いていることと、Webサーバーと同じプロセスの中でコンテンツを生成するプログラムが動作するため、CGIのように新たなプロセスを毎回起動する必要がなく、比較的高速に動作するということが利点でした。
Javaの優れた特徴をWebの世界に持ち込み、発展させたということですね。
ただJavaはエンタープライズ要素が強いので、なかなか個人開発では使用する機会がないです。
サーブレットのコードの例はこんな感じです。
mport java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Calc extens HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletEception,IOException {
// コンテキストタイプの設定
response.setContentType("text/html;charset=Shift_JIS");
// HTML出力の準備
PrintWriter out=response.getWriter();
// HTMLの出力
out.println("<html><head>");
out.println("<title>Calcurator</title>");
out.println("</head><body>");
out.println("<p>1000円の税込み価格 ="+ (1000 * 1.08) +"円</p>");
out.println("</body></html>");
// HTML出力の完了処理
out.flush();
out.close();
}
}
今見ると可読性が悪いですね。
HTML部分を追うのに一苦労です。
サーブレットのコードは、レガシーPHPに通づるものがあると考えています。
サーブレットの弱点を改善したJSP(Java Server Pages)の誕生
サーブレットの弱点は、画面デザインの変更が初制するたびに、プログラムの変更が必要になること。
さらに、Javaのソースコードの中にHTMLが点在するため、可読性が悪いことです。
この弱点、ノンフレームワークのPHPプロジェクトに類似する部分がありますよね
これを解消したものがJSP(Java Server Pages)です。
<html> <head> <title>Calcurator</title> </head> <body> <p>1000円の税込価格 = <% out.println(1000 * 1.08); %> 円</p> </body> </html>
これってRailsとかCakePHPのview部分に似てますね。
用途の近しい技術は類似していくんですね。
感想
最初は自分用のまとめにしようと思ったのですが、段々熱が入り、少しでもまとめようという気持ちが出てきました。
しかし、読み手を考えると、書籍の感想のまとめは難しく、結局前半部分しかまとめられませんでした。
後半は、何か別の書籍とミックスしたいと思います。
