2024年02月27日

書籍「Webを支える技術」を読んでみて得た学びについて

Webを支える技術

はじめに

デジタルエンジニアリング部の田中です。
本記事では書籍「Webを支える技術」を読み、私自身が学びになったテーマをいくつか抜粋し内容を紹介したいと思います。
Webを支える技術 -HTTP、URI、HTML、そしてREST amazonリンク

想定読者

Webシステムに興味がある人
Webシステムの開発に従事している人

テーマについて

書籍「Webを支える技術」について、今回紹介するテーマを以下に記述します。

REST
Webシステムの設計原則の一つであるRESTについての内容になります。
URIの設計
URIを設計する上での要点についての内容になります。
HTTPメソッド
HTTPメソッドの性質についての内容になります。
HTTPステータスコード
HTTPステータスコードとコードを用いた実装についての内容になります。

REST

ネットワークシステムのアーキテクチャスタイルとして最も有名なのはクライアント/サーバでWebシステム開発に携わっている方であれば馴染みがあるかと思います。
そしてクライアント/サーバにWebシステムを設計する上で様々な制約を付与していったものがRESTになります。

RESTはネットワークシステムのアーキテクチャスタイルとして使用され、WebシステムやAPIの設計にも広く適用されます。
以下にRESTの構成を示します。

基盤：クライアント/サーバ

RESTはアーキテクチャスタイルの基盤としてクライアント/サーバを採用しています。
クライアント/サーバは、Webシステムの役割をクライアントとサーバに分離します。

クライアントはユーザやアプリケーションのリクエストを送信し、サーバはそれを受け取って処理しリソースを返却します。
一連の流れについてはネットワークを通じた通信を介して行われ、Webシステムに効率性とセキュリティを付与できるのが利点です。
クライアントとサーバを分離する構造が基盤であることにより、WebはPC等の特定の端末だけでなく携帯電話やゲーム機からもアクセスできる仕組みになっています。

制約①：ステートレスサーバ

最初に追加する制約は、ステートレスサーバです。
この制約はクライアントとサーバ間の通信においてサーバがクライアントの状態を保持せず、リクエストを独立して処理する仕組みです。
またサーバが前回のリクエストや状態を覚えずすべての情報がリクエストに含まれるためシンプルで再利用可能な実装が可能です。

制約②：キャッシュ

次に追加する制約は、キャッシュです。
この制約はシステム内にキャッシュと呼ばれる一時的なデータストレージを導入することを重視します。
キャッシュは一時的によくアクセスされるデータを保持しデータの取得処理を高速化することができます。
ただし、古いキャッシュを利用してしまい情報の信頼性が下がる可能性がある点には注意が必要です。

制約③：統一インタフェース

3番目に追加する制約は、統一インタフェースです。
この制約はクライアントとサーバ間の通信に一貫性のあるインタフェースを用いる仕組みです。
これにより異なるリソースやサービスに対して統一的なアクセス方法が確立され、クライアントがサーバの内部構造を知る必要がなくシステムを開発することができます。

例えばHTTPメソッド（GET、POST、PUT、DELETEなど）を使用することで、リソースへのアクセスや変更を一貫して行うことができるため、シンプルで拡張性のあるアプリケーションを構築しやすく、クライアントとサーバが疎結合になる利点があります。

制約④：階層化システム

4番目に追加する制約は、階層化システムです。
この制約はシステムをいくつかの階層に分離する仕組みです。
この制約は「制約③：統一インタフェース」の利点でシステム全体が階層化しやすいこととも繋がりがあります。
階層化システムを取り入れることで、各コンポーネント間のインタフェースが統一され、異なるコンポーネントを簡単に接続できるようになります。

例えばインタフェースが統一されることで、クライアントとサーバの間にロードバランサを設置して負荷分散をしたりすることができるなど、システムの構造を柔軟に変化させることができます。

制約⑤：コードオンデマンド

最後に追加する制約は、コードオンデマンドです。
この制約はクライアントが必要に応じてサーバから実行可能なコードをダウンロードして実行できる仕組みです。
代表的な例を挙げるとJavaScriptが該当します。
主にWebブラウザやモバイルアプリで使用され、サーバからスクリプトを取得し、クライアントで実行することができます。

これによりアプリケーションの柔軟性や機能拡張性が向上し、サーバ側のアップデートを必要とせずにクライアントアプリケーションを更新できます。

そしてクライアント/サーバを基盤にこれらの5つの制約を追加したものがRESTで、Webという巨大なシステムが動作する上で非常に大きな役割を果たしています。

URIの設計

URIの設計ではポイントがいくつかありますが、ここでは特に重要である「URIの不変性」に重きを置き設計の重要性を考えます。
以下に「URIの不変性」の要点について記載します。

URIの不変性
URIは常に一定で変更されずに、特定のURIが特定のリソースを指し続けることが期待されます。

これらを遵守することは、ユーザが特定の情報やコンテンツが信頼性のある場所に常にアクセスできるというアクセシビリティに繋がります。
URIが頻繁に変更されると、ユーザはリソースを見つけることが難しくなり、リンクの信頼性が低下してWebシステムのユーザの定着率が下がってしまいます。
そのため、設計段階でできる限り変わりにくいURIに設計することが重要になります。

変わりにくいURIとは、以下のような要件を満たすものになります。

プログラミング言語に依存した拡張子やパスを含めない
「cgi-bin」や「servlet」などの特定の言語のみで扱うパスを含めない
「Login●●」等のJava特有の先頭を大文字にする記述法を使用しない

これらは全て、システムのリプレイス対応が発生した際にURIが変更になるリスクを抱えています。

しかしドメインの変更などでURIが変わってしまうことが避けられない場合があります。
そのようなやむを得ない場合には、HTTPサーバが用意しているリダイレクト機能を使い、できる限り古いURIから新しいURIに転送することが大切です。

HTTPメソッド

HTTPメソッドとは、HTTPを使用してクライアントとWebサーバ間で通信する際にどのような操作を行うかを示すメソッドの一種です。
各メソッドはリクエストの性質で分類し、サーバに対して実行されるアクションを指定します。

HTTPメソッドは8個のメソッドから構成されますが、本記事では主にWebシステムのCRUD操作で使う4つのメソッドを抜粋し、各メソッドの持つ性質を記載します。

GET: リソースの取得をリクエストします。

特定のURIに対するデータを取得し、サーバからクライアントに返します。データの読み取り専用メソッドです。

POST: リソースの作成または更新をリクエストします。

新しいデータを送信し、サーバ上で新しいリソースを作成するか、既存のリソースを更新します。主にフォームデータの送信に使用されます。

PUT: 特定のURIに対するリソースを更新または置き換えます。

リソースが存在する場合、そのリソースを新しいデータで置き換えます。存在しない場合は新しいリソースを作成します。

DELETE: 特定のURIに対するリソースの削除をリクエストします。

リソースを削除するために使用されます。

メソッドの性質について

HTTPメソッドには冪等性と安全性があり、HTTPプロトコルにおけるリクエストメソッドを表す重要な性質になります。
以下にそれぞれの性質の詳細と各HTTPメソッドが持つ性質の表を記載します。

冪等性:

冪等性は、同じリクエストを何度実行しても、同じ結果が得られるかどうかを示す性質です。
冪等なメソッドは、リクエストの重複実行による影響がないため予測可能な動作を提供します。

安全性:

安全性は、リクエストがサーバ上のデータを変更しないかどうかを示す性質です。
安全なメソッドは、リソースの読み取りや状態の取得に使用され、リソースへの変更を伴わないため、リクエストがデータを変更しないことを保証します。

HTTPメソッド	冪等性	安全性
GET	Yes	Yes
PUT	Yes	No
DELETE	Yes	No
POST	No	No

この表のとおり、GETは冪等かつ安全でPUTとDELETEが冪等であることはHTTPの仕様として定められています。
そのため、以下のような例は適切ではありません。

GETの処理内でリソースに変更を加える
GET /api/●●/1/delete/ のような安全性を失うエンドポイントを作成しない
PUTの処理結果が一意でない
ある商品を値上げする処理を行う際に、10%アップのように相対的な差分による冪等性を失う処理は作成しない
DELETEの発行ごとに別のリソースを削除する
'http://●●.co.jp/latest/' というリソースが最新バージョンのリソースを示す場合、冪等性が損なわれるため時間や状況で変化するリソースは削除できないようにする

上記のDELETEの例に関してはリソースの在り方によりますが、GETやPUTの例では安全性や冪等性の関係でPOSTを使うことが可能です。
POSTは安全でなくかつ冪等でないため、他のメソッドでは対応できない処理を行うことに適しています。
しかしPOSTを多用すると他のメソッドの持つ性質が利用できなくなる点には注意が必要です。

そのためGET、PUT、DELETEで実現できるものに関してはそれらで実装を行い、それらで実現できないものについてはPOSTを使うのがHTTPメソッドとしてのあるべき姿です。

HTTPステータスコード

HTTPステータスコードとは、WebブラウザとWebサーバの間の通信結果を示す3桁の数値からなるコードです。
これらは先頭の1桁でレスポンスの状態（成功やエラー等）がカテゴリ分けされ、処理内容に適した値を返却することがシステム開発において重要になります。主要なカテゴリと代表的なステータスコードを以下に記載します。

1xx: 情報メッセージ - リクエストの受付や処理継続を示すカテゴリ。
100 Continue: クライアントがリクエストを送信し、サーバがリクエストを受け入れたことを示す。
2xx: 成功 - リクエストが正常に処理されたことを示すカテゴリ。
200 OK: リクエストが成功し、サーバから要求されたコンテンツが正常に返されたことを示す。
201 Created: サーバが受信したクライアントのリクエストに従い、新しいリソースの作成に成功したことを示す。
3xx: リダイレクト - 他のリソースへのリダイレクトを行うことを示すカテゴリ。
301 Move Permanently:リクエストで指定したリソースが新しいURIに移動したことを示す。
303 See Other: リクエストに対する処理結果が別のURIで取得できることを示す。
4xx: クライアントエラー - クライアントのリクエストに問題があることを示すカテゴリ。
401 Unauthorized: 対象のリソースにアクセスするのに認証が必要であることを示す。
404 Not Found: リソースが見つからないことを示す。
5xx: サーバエラー - サーバがリクエストの処理に失敗したことを示すカテゴリ。
500 Internal Server Error: 一般的なサーバエラーを示す。
503 Service Unavailable: サーバがメンテナンス等で一時的にアクセスできないことを示す。