はじめに
10月からWeb開発エンジニアに転職したそらです!
今回は、Webを支える技術 ―― HTTP,URI,HTML,そしてRESTを読んだので、まとめてみます!
WebAPIの歴史
2000年前後に、SOAP(RPC/分散オブジェクトの基本的なプロトコル)とRESTの論争が繰り広げられていた。
2004年から始まったWeb2.0の流れで、色々なWebAPIが提供する情報を組み合わせて一つのアプリを実現するマッシュアップが普及したことで、RESTに軍配が上がった。
REST(Representatianal State Transfer)
Webのアーキテクチャスタイルの一つである。
アーキテクチャスタイルは、複数のアーキテクチャに共通する性質や様式、作法を指す言葉で、システムのアーキテクチャを設計するときの指針となるものである。
RESTは、ネットワークシステムのアーキテクチャスタイルで、クライアント/サーバから派生したアーキテクチャスタイルで、6つの特徴がある。
- クライアントとサーバが分かれていること
- ステートレスであること
- キャッシュによって通信量が削減されること
- インタフェースが統一されていること
- システム全体が階層化できること
- プログラムをDLして実行できること
URIの設計
プログラミング言語に依存した拡張子やパスを含めない
ファイル拡張子やプログラミング言語のディレクトリ構成に依存したURIにすると、言語を変えたりした場合にそのURIが使えなくなってしまう。
例)http://exmple.jp/login.pl / http://example.jp/servlet/login
メソッド名やセッションIDを含めない
呼び出したいメソッド名やセッションIDを含めたURIにすると、リファクタリングによってメソッド名が変更された場合やログインし直してセッションIDが変わるとURIが変わってしまう。
例)http://example.jp/login?action=xxxMethod / http://example.jp/home?sessionid=123456
リソースを表現する名詞を使う
URIはリソースの名前であるため、何のリソースかわかるURLにするべきである。
例)http://example.jp/people/show/123 → http://example.jp/people/123
HTTP
TCP/IP
HTTPは、TCP/IPをベースとしている。
TCP/IPは階層型プロトコルとなっていて、アプリケーション層、トランスポート層、インターネット層、ネットワークインタフェース層の4層から成り立っている。
- ネットワークインタフェース層
→物理的なケーブルやネットワークアダプタに該当する - インターネット層
→ネットワークでデータを実際にやり取りする部分 - トランスポート層
→インターネット層で保証しなかったデータ転送を保証する - アプリケーション層
→具体的なインターネットアプリケーション(メールやDNSやHTTP)を実現する
HTTP通信においてクライアントで行われる処理
- リクエストメッセージの構築
- リクエストメッセージの送信
- レスポンスが来るまで待機
- レスポンスメッセージの受信
- レスポンスメッセージの解析
- レスポンスメッセージ受信後の処理
HTTP通信においてサーバーで行われる処理
- リクエストの待機
- リクエストメッセージの受信
- リクエストメッセージの解析
- 適切なプログラムへ処理を委譲
- プログラムからの結果を取得
- レスポンスメッセージの構築
- レスポンスメッセージの送信
HTTPメソッドにおけるべき等性と安全性
べき等とは、「ある操作を何回やっても結果が同じであること」を意味する。
安全とは、「操作対象のリソースの状態を変化させないこと = 副作用がないこと」を意味する。
| HTTPメソッド | べき等 | 安全 |
|---|---|---|
| GET / HEAD | ○ | ○ |
| PUT / DELETE(※) | ○ | ✖︎ |
| POST | ✖︎ | ✖︎ |
※DELETEは、/latestのようにその時の最新版などを表す場合、1回目と2回目の呼び出し結果が変わる可能性があるため、この時はべき等ではない
よく使われるステータスコード
| ステータスコード | 説明 |
|---|---|
| 200 OK | リクエストが成功したことを示し、ボディにリソース表現が入る |
| 201 Created | リソースの作成成功を示す |
| 301 MovedPermanently | リソースが新しいURIに移動したことを示し、Locationヘッダに新しいURIが入る |
| 303 SeeOther | 処理結果が別のURIで取得できることを示す |
| 400 BadRequest | リクエストの構文やパラメータが間違っていることを示す |
| 401 Unauthorized | 適切な認証情報を与えずにリクエストを行ったことを示す |
| 404 NotFound | 指定したリソースが見つからないことを示す |
| 500 InternalServerError | サーバ側に何らかの異常が生じて正しいレスポンスが返せないことを示す |
| 503 ServiceUnavailable | メンテナンスなどで一時的にアクセスできないことを示す |
キャッシュ
キャッシュとは、サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法のこと。
そのキャッシュが有効な間、クライアントが再度そのリソースにアクセスしようとするときに再利用する。
ヘッダの各情報で再利用可能かどうかを判断する。
| ヘッダ | 役割 |
|---|---|
| Pragma | リソースをキャッシュしてはならないことを示す |
| Expires | キャッシュの有効期限を示す |
| Cache-Control | 詳細なキャッシュ方法を示す(相対時間で有効期限を指定できる) |
HTML
ブロックレベル要素
文章の段落や見出しなどのある程度大きな塊を表現する。
| 要素 | 意味 |
|---|---|
| h1,h2,h3,h4,h5,h6 | 見出し |
| dl,ul,ol | リスト |
| div | ブロックレベル要素のグループ化 |
| p | 段落 |
インライン要素
ブロックレベル要素の中に入る要素で、強調や改行、画像の埋め込みなどを表現する。
| 要素 | 意味 |
|---|---|
| em | 強調 |
| code | ソースコード |
| samp | 例 |
| var | 変数 |
| img | 画像 |
リンクのrel属性
<a>, <link>で、リンク元のリソースとリンク先のリソースがどのような関係にあるかを記述する。
HTMLで最も使われているのは、「stylesheet」である。
- microformats
HTMLが定義しているリンク関係以外の様々なリソースを表現する
| リンク関係 | 意味 |
|---|---|
| alternate | 翻訳などの代替文書へのリンク |
| stylesheet | 外部スタイルシートへのリンク |
| start | 文書群の最初の文書へのリンク |
| next | 文書群の次の文書へのリンク |
| prev | 文書群の前の文書へのリンク |
| bookmark | 文書中のブックマークへのリンク |
JSON
JavaScriptObjectNotationの略で、JavaScriptの記法でデータを記述できるのが特徴。
シンプルな構成のため、多くの言語で利用されている。
{
{
"text": "sampleText",
"object: {
"content1": "sampleContent1",
"content2": "sampleContent2"
},
"array": ["item1","item2","item3"],
"num": 123,
"bool": true
}
}
リソース設計
クライアントとサーバの間のインタフェースの設計のこと。
どのようにリソースを分割し、URIで名前をつけ、相互にリンクを持たせるかを決めていく。
- Webサービスで提供するデータを特定する
- データをリソースに分ける
- 各リソースにURIで名前をつける各リソースにURIで名前をつける
- クライアントに提供するリソースの表現を設計する
- リンクとフォームを利用して、リソース同士を結びつける
- イベントの標準的なコースを検討する
- エラーについて検討する
郵便番号検索サービスを例としたリソース設計
1. Webサービスで提供するデータを特定する
1データは、7桁の郵便番号・その郵便番号が表現する住所(都道府県、市町村、町域)・住所のカタカナ読みを持つ。
2. データをリソースに分ける
- 郵便番号リソース
1つの郵便番号に対応するリソース - 検索結果リソース
郵便番号の一部や住所の一部で検索した結果のリソース - 地域リソース
都道府県・市区町村・町域のリソースで、上位の地域は下位の地域の情報を含む - トップレベルリソース
Webサービスのスタート地点で、都道府県リソースのリンクと検索フォームを含む
3. 各リソースにURIで名前をつける
- 郵便番号リソース
郵便番号で一意に識別できるため、郵便番号を使用したURIにする - 検索結果リソース
検索キーワードの入力を必要とし、クエリパラメータを受け取る - 地域リソース
地域リソースは、都道府県 > 市区町村 > 町域と階層を持っているため、「/」を使って表現する - トップレベルリソース
Webサービスのスタート地点となるため、ルートとなるURIにする
4. クライアントに提供するリソースの表現を設計する
1つのリソースが複数の表現形式をサポートしていると、利用する側が選べるため便利になる。
郵便番号データの場合、XML表現は「XHTML」、軽量フォーマット表現は「JSON」ろ利用する。
この時に、リクエストのヘッダだけでなく、URIによってもリソースを選択できるようにする。
例)http://postNum.jp/1120002.html / http://postNum.jp/1120002.json
5. リンクとフォームを利用して、リソース同士を結びつける
これまで設計してきたリソース同士をリンクで接続していく。
検索結果のリソースから、各郵便番号リソースへリンクを貼ったり、地域リソースから上位地域や下位地域、郵便番号リソースへリンクを貼ったりしていく。
6. イベントの標準的なコースを検討する
Webサービスを利用する上でのコースを設計する。
-
郵便番号を検索するコース
① フォームに郵便番号を入力
② 検索結果リソースを取得
③ 目的の郵便番号リソースを取得 -
住所から郵便番号を検索するコース
① フォームに住所を入力
② 検索結果リソースを取得
③ 目的の郵便番号リソースを取得 -
地域リソースの階層をたどりながら、郵便番号を選択するコース
① 都道府県リソースを選択し、市区町村一覧を表示
② 市区町村リソースを選択し、町域一覧を表示
③ 町域リソースを選択し、郵便番号一覧を表示
④ 目的の郵便番号リソースを取得
7. エラーについて検討する
存在しないURIを指定された場合や、必須パラメータを指定していない場合、サポートしないメソッドを使用した場合などにどのような結果を返すのか設計する。