Webを支える技術 ―― HTTP,URI,HTML,そしてREST WEB+DB PRESS plus [Kindle]
- 技術評論社 (2018年11月14日発売)
本棚登録 : 395人
感想 : 24件
本ページはアフィリエイトプログラムによる収益を得ています
Amazon.co.jp ・電子書籍 (674ページ)
感想・レビュー・書評
-
知らないことも結構学べたが、規格の説明が多くて少し退屈だった。
HTTP について学べたのが良かった詳細をみるコメント0件をすべて表示 -
普段使ってるwebについて理解が深まったかな。
インフラエンジニアには少しだけ難しいところもあった。。 -
後半がとくによかた!
-
URI、HTTP、HTMLというwebを支える技術について基本的な知識を得られてwebとはなんなのか、身になったとてもいい本だと思います。
-
当時は良い本だったかもしれないが、流石に書かれている内容が古くなってきて、紙面の半分以上をすでに廃れた技術の説明に費やしており、おすすめできる本ではなくなってきたという印象。
-
5部のリソース設計の具体的な話が良かった 第2版とか出ないかな
-
なんとなくで使っていたものがしっかりと言語化されていた。
-
HTTP, HTML, URIをWebサービスを作る側として理解するのにちょうどいい本。
約10年前の本なので最新のWebのトレンドはカバーしていないが、HTTP, HTML, URIと、Webの根幹にある技術を理解できる。URIが指し示すWebのリソースはいくつかの表現を持ち得またその状態が変化し得る、と理解できたのがよかった。 -
-
Webの根底となる考え方が書いてあるので良かったと思う。
-
古典
-
Webの歴史、REST、URI、HTTPなど、今も変わらず使われている技術が体系的に説明されており、理解しやすかったです。
10年前の本ですがベースとなる部分は変わっていないので読む価値はあると思います。 -
1章 Webとはなにか
Webを支える技術はHTTP,URI,HTMLである。
2章 Webの歴史
Webはいきなり発生したわけではなくその前にいろんな試みがありその1つの試みであるWebが成功をおさめ世界に広がった。標準化のためにW3Cが設立された。標準化の対象はHTML,XML,HTTP,URI,CSSである。
3章 REST Webのアーキテクチャスタイル
リソースを区別するためのものがURI。RESTを構成するもの。クライアント/サーバアーキテクチャスタイル。ステートレスサーバ、キャシュ、統一インターフェイス階層化システム、コードオンデマンド
4章 URIの仕様
URIスキーム:http
ホスト名:blog.example.jp
パス:/entries/1
URIを表現するのはA-Za-z,0-9,-.~:@!$&()で日本語は入らない。なので日本語をURIに入れる場合は%エンコーディングを施す。
5章 URIの設計
省略
6章 HTTP
省略
7章 HTTPメソッド
HTTPにはメソッドが8つある
GET リソースの取得
POST リソースの作成、追加
PUT リソースの更新、作成
DELETE リソースの削除
HEAD リソースのヘッダの取得
OPTIONS リソースがサポートしているメソッドの取得
TRACE *1
CONNECT *1
*1 ほとんど使用されていない
8章 ステータスコード
1**:処理中
2**:成功
3**:リダイレクト
4**:位案テラー
5**:サーバエラー
9章 HTTPヘッダ
HTTPのヘッダは電子メールヘッダに追加されて作られた。
10章 HTML
HTMLは文書に構造を与えるためのもの
11章 microformats
省略
12章 Atom
省略
13章 Atom Publishin Protocol
省略
14章 JSON
もともとはJavaScriptのObjectを記述する方法であったが扱いやすいことから各プログラミング言語間のデータ授受に使われている。
15章 読み取り専用のWebサービスの設計
これまでの知識を生かして読み取り専用の郵便番号検索サービスを設計する。
16章 書き込み可能なWebサービスの設計
書き込み可能な郵便番号番号サービスの設計
17章 リソースの設計
省略 -
RESTについて勉強するために入手。
-
ターゲットはWebサービス開発者。
Webサービスの設計はどうあるべきか、Webの思想から解いている本。やや抽象的でテーブル設計やクラス設計の前段を理解した気になれる。
本書で得る知識が、Webサービス開発者としてすぐに役立つ知識かと言われればそうではないかもしれない。しかし、設計作業の土台となる教養のような知識であると言えよう。
Webの素晴らしさはシンプルなアーキテクチャにある。
Web以前に存在したハイパーメディア(非線形な情報媒体)は相互リンクによる複雑さが問題であった。
Webは単方向リンクは採用することでリンク切れする可能性があるという弱点はあるものの、Webをシンプルに保つことに成功した。
リンク切れを起こさないよう設計するとハイパーメディアを複雑にしてしまう。
この事象を抽象化して解釈すると、「部分最適は全体のシンプルさを損なうことにつながる」ということだと思ったので今後設計する際に気をつけたい。
Webサービスを設計する際も、Web同様にシンプルに保つことが重要である。
そのためのWebサービスの設計を抽象化すると、次のようになる。
(本書に述べられているリソース指向アーキテクチャよりさらに簡略化している)
提供するデータを特定する
↓
リソース(WebページやURLの構成)に分解する
↓
リンクとフォームでリソース同士を結び付ける
↓
画面の遷移を検討する
↓
エラーパターンを検討する -
Webを支える技術
リコーのエンジニアである山本陽平さんの著書です。
Webサービスを構築する上で欠かせない基本的な技術を解説し、Webサービスの設計指針までをまとめた本になります。
【本書で学べること・考えること】
・Webとは何か
・Webの歴史
・REST、RESTful
・URI
・HTTP、HTTPメソッド
・ハイパーメディアフォーマット(HTML、microformats、Atom、AtomPub、JSON)
・Webサービスの設計指針
読んでみての感想です。
独学でプログラミングを学んでいるのですが、ある方からWebの基本を押さえておくべきでその内容はこの本に書いてあると薦められて読みました。
Webの歴史、REST、URI、HTTPなど、今も変わらず使われている技術が体系的に説明されており、理解しやすかったです。
当初の目的であったWebの基本を押さえることはできたと思います。
この本が発行されたのが2010年で私の購入した版が11版なのでベストセラーとして読まれている良書です。
ただ、10年の歳月が流れているため、状況が大きく変わっている部分もあります。
第4部のハイパーメディアフォーマットなどがそうです。
HTML4.01はHTML5にかわり、Atomなどを利用したRSSリーダーなども大きく減りました。
JSONは変わらずに活用されています。
設計指針については、私自身の勉強不足で最近のトレンドはわかりませんが、基本的な考え方は現在でも変わっていないと思います。
良書なので、一部内容を現状に合わせた第2版が出版されても良いと思いました。 -
Webのお勉強。
…実装から抽象度を1つ上げたのがアーキテクチャで、アーキテクチャから抽象度を1つ上げたのがアーキテクチャスタイルです。…
RESTはWeb全体のアーキテクチャスタイルでもあり、個別のWebサービスやWebAPIのアーキテクチャスタイルでもあります。
リソースを一言で説明すると、「Web上に存在する、名前を持ったありとあらゆる情報」となります。
現在のWebが多様なクライアントやサーバの実装で構成されていることには、統一インターフェースが一役買っています。統一インターフェースはRESTを最も特徴づけるアーキテクチャスタイルです。
コードオンデマンドは、プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイルです。たとえばJavaScriptやFlash、Javaアプレットなどがこれに該当します。
■URIの設計指針
・URIにプログラミング言語依存の拡張子を利用しない
・URIに実装依存のパス名を利用しない
・URIにプログラミング言語のメソッド名を利用しない
・URIにセッションIDを含めない
・URIはそのリソースを表現する名刺である
ステートフルなプロトコルの代表例はFTPです。FTPではクライアントがFTPサーバにログインしてからログアウトするまで、そのクライアントがどのディレクトリにいるかといったアプリケーション状態をサーバが管理します。
べき等とは「ある操作を何回行っても結果が同じこと」を意味する数学用語です。たとえばPUTとDELETEはべき等ですので、PUTやDELETEを同じリソースに何回発行しても、必ず同じ結果(リソースの内容が更新されている、リソースが削除されている)が得られます。
安全とは「操作対象のリソースの状態を変化させないこと」を意味します。リソースの状態に変化を与えることを副作用と言いますので、安全は「操作対象のリソースに副作用がないこと」とも言います。たとえばGETには副作用がないので、GETを同じリソースに何回発行してもリソースの状態は変化しません。
■ステータスコード
・1xx:処理中
・2xx:成功
・3xx:リダイレクト
・4xx:クライアントエラー
・5xx:サーバエラー
結局のところWebにおける意味論とは、HTMLやXMLで書かれたリソースの意味をどのようにプログラムから処理するか、に尽きるでしょう。人間が読んで理解するWebページの意味を、プログラムからも処理できるように形式的に意味を記述するための技術がセマンティックWebです。
■Atom
Atomにおける最小のリソース単位がメンバリソースです。たとえば、ブログであれば一つ一つの記事がメンバリソースになります。画像保管サービスであれば一つ一つの画像がメンバリソースになります。
メンバリソースはXMLで表現できるエントリリソースとそれ以外のメディアリソースに分かれます。
エントリリソースはたとえば、ブログ記事の本文と、それに対応するメタデータ(タイトル、日時、著者など)がまとまった、テキストやXMLで表現するリソースです。エントリリソースは<entry>要素で表現し、この表現のことを「エントリ」と呼びます。
メディアリソースは、画像や映像などテキストでは表現できないリソースです。メディアリソースのメタデータはメディアリンクエントリという特別なリソースで表現します。
…Atomはタイトル、著者、更新日時といった基本的なメタデータを備えたリソース表現のためのフォーマットです。タイトル、著者、更新日時のメタデータ3点セットは、ブログ以外のコンテンツでも有用なことが多いでしょう。
Atomは多様なアプリケーション用の拡張が用意されたフォーマットでもあります。この拡張性により、Atomはブログ以外の用途にも用いられています。たとえばポッドキャストによる音楽配信や、写真管理、検索エンジンなどです。
■Atom Pub
・Atom:データフォーマットの規定(フィード、エントリ)
・Atom Pub:Atomを利用したリソース編集プロトコルの規定
AtomPubは、Atomが規定したフィードやエントリで表現するリソースの編集、いわゆるCRUD操作を実現するためのプロトコルです。
・Atom Pubに向いているWeb API
・ブログサービスのAPI
・検索機能を持つデータベースAPI
・マルチメディアファイルのリポジトリのAPI
・タグを使ったソーシャルサービスのAPI
・Atom Pubに向いていないWeb API
・Cometを利用するような、リアルタイム性が重要なAPI
・映像のストリーム配信など、HTTP以外のプロトコルを必要とするAPI
・データの階層構造が重要なAPI
・「タイトル」「作者」「更新日時」など、Atomフォーマットが用意するメタデータが不要なAPI
…リソース設計とは、クライアントとサーバの間のインターフェースの設計、つまりWebサービスやWeb APIの外部設計です。どのようにリソースを分割し、URIで名前を付け、相互にリンクを持たせるかが設計の勘所になります。
設計とは、システムをどのような構成でどのように開発するのかを検討し、図や文書に残す作業です。設計図、設計書を作る作業とも言えます。ではリソースの設計図とは何かと言えば、たとえば、リソースの種類、リソースの表現、リソースの操作方法、リソースとリソースのリンク関係などです。
WebサービスとWeb APIを分けて考えない、これが、リソース設計で最も重要な考え方です。
■情報アーキテクチャ
Webデザインというのは、従来の紙の上での2次元のグラフィックデザインと比べて、ユーザの操作やページ遷移、ネットワーク通信、アプリケーションの実行など、より複雑なデザインが必要となっています。情報アーキテクチャはこの複雑なデザインを、図書館情報学などの情報分類の観点から整理して、受け手にとって情報を探しやすくしたり、わかりやすくするための技術です。 -
Web系のエンジニアとしての基本的な知識が身につく。
特にHTTPやURLに関する章は必見。
著者プロフィール
山本陽平の作品
