サブ資料②Webシステムの基礎

2023年度リクルート エンジニアコース新人研修の講義資料です

Transcript

1. 1 ページ サブ資料②：Webシステムの基礎 主なWebサービス Webアプリ V（View）は、RESTful APIには直接関係な く、APIを使⽤するクライアントのアプリ ケーション、例えばスマートフォンアプ リやデスクトップアプリケーション等が、 Viewの役割を果たす Webアプリケーションの場合の形（通常） Webクライアント （ブラウザ） Controller リクエスト受付 View Webページの⽣成 Model ビジネスロジック 処理を実⾏ 画⾯表⽰ 処理結果参照 リクエスト レスポンス （画⾯表⽰） Webサーバ（MVCモデル） データベース RESTful API RESTful APIの場合の形 ※【補⾜】その他APIの種類 Web APIはRESTの他にSOAP APIやXML-RPC、GraphQL、gRPC等があるが、SOAPやXML-RPC はMVCアーキテクチャではない GET PUT POST DELTE Controller リクエスト受付 Model ビジネスロジック 処理を実⾏ リクエスト レスポンス APIサーバ データベース Controller / Model View クライアント
2. 2 ページ リクエストメソッド リソースの取得を要求する。サーバは要求されたリソースを返す。例えば、ウェブページ の表⽰や画像のダウンロードなどに使⽤される GET 通信プロトコル（HTTP / HTTPS） HTTPは、WebクライアントとWebサーバー間でデータをやり取りするためのプロトコルであり、 テキストや画像、ビデオなどのコンテンツを転送する。HTTPは、リクエストとレスポンスとい う形式で通信を⾏い、クライアントが要求を送信し、サーバーがそれに応答する仕組み。HTTP はデータの転送に暗号化を⾏わないため、情報は平⽂で送信される。 HTTP HTTPS ⼀⽅、HTTPSは、HTTPのセキュア版。HTTPSは、SSL（Secure Sockets Layer）もしくはTLS （Transport Layer Security）と呼ばれる暗号化のプロトコルを使⽤して、通信経路を暗号化する。 これにより、データが第三者によって傍受や改ざんされることを防ぐことができ、暗号化に SSLを⽤いたHTTPSが標準で⽤いられている プロトコルは規約や規格の意味 リクエストメソッドは、HTTPプロトコルにおいて、クライアントがサーバーに対して⾏い たいアクションや処理の種類を指定するための識別⼦です。クライアントがサーバーに対 して要求する処理の種類や意図を表現するために使⽤される。 よく使⽤されるメソッドには以下のものがある データの送信や新しいリソース（データ）の作成を要求する。クライアントからサーバに データを送信する POST リソースの更新を要求する。リクエストの本⽂に更新後のデータを含め、サーバ上の指定さ れたリソースを置き換える PUT リソースの⼀部の更新を要求する。リクエストの本⽂に更新内容を含め、サーバー上の指定さ れたリソースの⼀部を更新する。 PATCH リソースの削除を要求する。指定されたリソースをサーバから削除する DELETE 他にも、HEAD、OPTIONS、TRACE、CONNECTなどのリクエストメソッドもあるが、上記の5つが 最も⼀般的に使⽤されている
3. 3 ページ CRUDとは CRUD（クラッド）とはデータベースや情報システムにおける基本的な操作の⼀連の機能を表す⽤ 語で、以下の操作を指す。 Create（作成） Read（読み取り） Update（更新） Delete（削除） 新しいデータを作成します。これは、データベースに新しいレコードを挿⼊するなど、新しい 情報を⽣成する操作です。これに対応するHTTPリクエストメソッドは、通常は「POST」 データを取得します。これは、データベースから既存のレコードを検索して取得したり、情 報システムからデータを読み取ったりする操作です。 これに対応するHTTPリクエストメソッドは、通常は「GET」 データを更新します。これは、既存のデータを変更したり、データベース内の特定のレ コードを更新したりする操作です。これに対応するHTTPリクエストメソッドは、通常は 「PUT」または「PATCH」 データを削除します。これは、データベースからレコードを削除したり、情報システム内 のデータを削除したりする操作です。 これに対応するHTTPリクエストメソッドは、通常は「DELETE」 このように、HTTPプロトコルでは、CRUD操作に対応するリクエストメソッドを使⽤して データの操作を⾏う。RESTfulなAPIの設計では、リソースに対して適切なHTTPメソッドを使 ⽤することが推奨されている
4. 4 ページ リクエストヘッダとリクエストボディ リクエストヘッダ（Request Header） リクエストボディ（Request Body） リクエストヘッダは、HTTPリクエストメッセージの先頭に位置し、クライアントがサーバ に対して追加情報や要求を伝えるためのメタデータを含む。リクエストヘッダは以下のよ うな情報を含むことがある（それぞれ独⽴したヘッダの項⽬として分かれている） ・リクエストメソッド（GET、POST、PUT、DELETEなど） ・リクエストのターゲットURLやパス ・クライアントの情報（User-Agent） ・サーバーへの認証情報（Authorization） ・受け⼊れ可能なコンテンツの形式（Accept） ・クライアントがサーバーに対して期待するレスポンスの形式（Accept-Encoding） ・その他の追加情報やカスタムヘッダ リクエストヘッダとリクエストボディは、HTTPリクエストメッセージの2つの主要なコン ポーネントで、HTTPクライアントがサーバーに対して要求を⾏う際に重要な役割を果たす。 リクエストヘッダはメタデータやコンテキスト情報を提供し、リクエストボディは必要な データをサーバに送信する リクエストボディは、HTTPリクエストメッセージの⼀部であり、必要に応じてリクエスト に関連するデータやコンテンツを含む。リクエストボディは、主に以下のような場合に使 ⽤される ・POSTやPUTメソッド等、データをサーバーに送信する場合 ・ファイルのアップロード ・フォームリクエストやJSONデータのリクエストなどのコンテンツを送信する場合
5. 5 ページ メディアタイプ（MediaType）とは メディアタイプ（MediaType）は、インターネット上でのデータの表現形式やフォーマットを識 別するために使⽤される情報で、主にHTTPや電⼦メールなどのプロトコルで使⽤され、データ の受け渡しや解釈に関与する。 クライアントはリクエストヘッダの"Accept"フィールドに適切なメディアタイプを指定し、サー バーはレスポンスヘッダの"Content-Type"フィールドに実際のデータのメディアタイプを含める ことで、クライアントに対して適切なデータ形式を提供する 主なメディアタイプは以下 application/json application/xml application/x-www-form-urlencoded text/plain JSON形式のデータを表すメディアタイプ。リクエストボディにJSON形式のデータを含める場合 に使⽤され、多くのWeb APIでJSON形式のデータをやり取りする際によく使⽤されている XML形式のデータを表すメディアタイプ。リクエストボディにXML形式のデータを含める場合 に使⽤され、⼀部のAPIやWebサービスではXMLをデータ形式として使⽤している。 フォームデータを表すメディアタイプ。フォームの各フィールドとその値がURLエンコードさ れ、リクエストボディにキーと値のペアとしてエンコードされる。⼀般的なWebフォームの データ送信に使⽤される。 プレーンテキスト形式のデータを表すメディアタイプ。特定のフォーマットや構造を持たない テキストデータを含む場合に使⽤される multipart/form-data マルチパート形式のデータを表すメディアタイプ。フォームデータやファイルのアップロード など、複数のパートから構成されるデータをリクエストボディに含める場合に使⽤される。
6. 6 ページ ステータスコード（レスポンス） レスポンスコード（Response Code）は、HTTPプロトコルにおいて、サーバがクライアントに 返す応答のステータスを⽰す3桁の数字。クライアントがリクエストを送信した後、サーバは そのリクエストに対して適切なレスポンスコードを付与して返す。 レスポンスコードは、リクエストが成功したかどうか、エラーが発⽣したか、リダイレクトが ⾏われたかなど、さまざまな状態を表現する。以下は⼀般的なレスポンスコードの範囲とその 意味 1xx: インフォメーショナル（情報提供） 2xx: 成功 3xx: リダイレクト 4xx: クライアントエラー 5xx: サーバーエラー 具体的なレスポンスコードには、200 OK（成功）、404 Not Found（⾒つからない）、500 セッションとCookie HTTPは本来ステートレス（状態を管理しない）なプロトコルであるが、Webアプリケーションでの 状態管理を実現するためにセッションやクッキーといった仕組みが使⽤される セッションは、サーバー側でクライアントごとに状態を管理するための仕組み。セッションIDがク ライアントによって送信され、サーバーはそのセッションIDを使ってクライアントのセッションを 特定する。セッションにはサーバー上にデータを保存するためのメモリやデータベースが利⽤され ることが⼀般的 クッキーは、サーバーがクライアントのブラウザに保存する情報。サーバーはレスポンスヘッダに Set-Cookieヘッダを含めることで、クライアントにクッキーを送信する。その後、クライアントは リクエストごとにCookieヘッダを含めてサーバーに送信する。クッキーには期限を設けることがで き、有効期間内はクライアントがログアウトせずに再訪問した際にセッションの継続や認証情報の 保持が可能 セッション クッキー
7. 7 ページ URLについて https://api.example.com/v1/users?xx=yyyのようにホスト直下でバージョンを区切ると管理 しやすい URL⽂字列へIDの使⽤の可否について APIのバージョンの区切り⽅ 特定のリソースへアクセスする際のGETリクエストではhttps://{ホスト名}/xxxx/{id}のよう にURLパスにIDを表⽰させることは⼀般的に許可されているが、システムID（システム内 部で扱うID）をクライアント側にそのまま表⽰させることはリスクがあるため、暗号化 したり、表⽰⽤のIDを別で⽤意して管理する等することもある。また、POSTリクエスト ではパスにIDは使⽤しないことが多い URL（Uniform Resource Locator）は、インターネット上のリソース（ウェブページ、画像、 ビデオ、APIなど）を⼀意に特定するためのアドレスまたは識別⼦です。URLは、ウェブ ブラウザや他のクライアントがリソースにアクセスするための⼿段となります。 URLは⼀般的に以下のような構造を持つ。 Webシステムで⽤いられる主なDBの種類 リレーショナルDB MySQLやPostgreSQL等、データに関連を保持して保存できるDB。顧客情報等、重要な情報を扱 う場合の多くは、このDBを選択する リレーショナルデータベースは、例えば、顧客情報、注⽂データ、在庫情報など、データ間の 関連性や整合性が重要な役割を果たす場合や特に重要な情報やトランザクション性の⾼いデー タを扱う場合に選択されることが多い。 scheme://host:port/path?query 例）https://www.example.com:8080/books?hoge=fuga&xx=yy ・scheme (スキーマ) : リソースにアクセスするためのプロトコル（例: http、https、ftp） ・host (ホスト): リソースがホストされているドメイン名またはIPアドレス ・port (オプション) : リソースにアクセスするためのポート番号（80や443等デフォルトの ポートは通常省略されます） ・path (オプション) : サーバー上の特定のリソースのパス（ディレクトリ構造やファイル 名） ・query (オプション) : リソースに対する追加のパラメータやクエリ⽂字列。URLの後ろに? を付けた後、パラメータをkey=valueの形式で追加することができ、&で繋ぐことができる。 以下は具体例
8. 8 ページ インメモリDB No SQL DB 通常のデータベースはディスク上に保存されており、ファイル形式（バイナリ）でデータを格 納するが、これに対して、インメモリデータベースはデータをメモリ上に保持し、ディスクへ の読み書きが不要なため、⾼速な処理が可能となる。それにより、応答速度が向上する利点が ある反⾯、障害発⽣時の対応の考慮が必要（メモリは永続的なデータ保持はできない）になる。 セッションの管理等で使われることが多い NoSQLは、従来のリレーショナルデータベース（SQLデータベース）に代わる新しいデータ ベースのアプローチを指し、NoSQLデータベースは、データの柔軟性やスケーラビリティの要 求に応えるために開発された。従来のリレーショナルデータベースはスキーマに厳密に従う必 要があり、データベースの変更やスケールアップに制約があったが、NoSQLデータベースは柔 軟なデータモデルを提供し、⼤規模なデータセットや分散環境における処理を効率的に⾏うこ とができる。