Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サブ資料②Webシステムの基礎
Search
Recruit
PRO
August 10, 2023
Technology
1
1.9k
サブ資料②Webシステムの基礎
2023年度リクルート エンジニアコース新人研修の講義資料です
Recruit
PRO
August 10, 2023
Tweet
Share
More Decks by Recruit
See All by Recruit
dbtとBigQuery MLで実現する リクルートの営業支援基盤のモデル開発と保守運用
recruitengineers
PRO
3
84
『ホットペッパービューティー』のiOSアプリをUIKitからSwiftUIへ段階的に移行するためにやったこと
recruitengineers
PRO
4
1.6k
経営の意思決定を加速する 「事業KPIダッシュボード」構築の全貌
recruitengineers
PRO
4
240
Browser
recruitengineers
PRO
12
3.4k
JavaScript 研修
recruitengineers
PRO
8
2k
TypeScript入門
recruitengineers
PRO
37
14k
モダンフロントエンド 開発研修
recruitengineers
PRO
13
7.6k
Webアクセシビリティ入門
recruitengineers
PRO
4
2k
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
4
2.6k
Other Decks in Technology
See All in Technology
『バイトル』CTOが語る! AIネイティブ世代と切り拓くモノづくり組織
dip_tech
PRO
1
120
How to achieve interoperable digital identity across Asian countries
fujie
0
150
やる気のない自分との向き合い方/How to Deal with Your Unmotivated Self
sanogemaru
0
490
そのWAFのブロック、どう活かす? サービスを守るための実践的多層防御と思考法 / WAF blocks defense decision
kaminashi
0
190
スタートアップにおけるこれからの「データ整備」
shomaekawa
2
420
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
310
"プロポーザルってなんか怖そう"という境界を超えてみた@TSUDOI by giftee Tech #1
shilo113
0
180
CoRL 2025 Survey
harukiabe
0
170
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
570
リセラー企業のテクサポ担当が考える、生成 AI 時代のトラブルシュート 2025
kazzpapa3
1
160
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
6
1.1k
from Sakichi Toyoda to Agile
kawaguti
PRO
1
120
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Why Our Code Smells
bkeepers
PRO
339
57k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Leading Effective Engineering Teams in the AI Era
addyosmani
3
360
RailsConf 2023
tenderlove
30
1.2k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Agile that works and the tools we love
rasmusluckow
331
21k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Automating Front-end Workflow
addyosmani
1371
200k
Transcript
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 ページ リクエストメソッド リソースの取得を要求する。サーバは要求されたリソースを返す。例えば、ウェブページ の表⽰や画像のダウンロードなどに使⽤される 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 ページ CRUDとは CRUD(クラッド)とはデータベースや情報システムにおける基本的な操作の⼀連の機能を表す⽤ 語で、以下の操作を指す。 Create(作成) Read(読み取り) Update(更新) Delete(削除) 新しいデータを作成します。これは、データベースに新しいレコードを挿⼊するなど、新しい
情報を⽣成する操作です。これに対応するHTTPリクエストメソッドは、通常は「POST」 データを取得します。これは、データベースから既存のレコードを検索して取得したり、情 報システムからデータを読み取ったりする操作です。 これに対応するHTTPリクエストメソッドは、通常は「GET」 データを更新します。これは、既存のデータを変更したり、データベース内の特定のレ コードを更新したりする操作です。これに対応するHTTPリクエストメソッドは、通常は 「PUT」または「PATCH」 データを削除します。これは、データベースからレコードを削除したり、情報システム内 のデータを削除したりする操作です。 これに対応するHTTPリクエストメソッドは、通常は「DELETE」 このように、HTTPプロトコルでは、CRUD操作に対応するリクエストメソッドを使⽤して データの操作を⾏う。RESTfulなAPIの設計では、リソースに対して適切なHTTPメソッドを使 ⽤することが推奨されている
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 ページ メディアタイプ(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 ページ ステータスコード(レスポンス) レスポンスコード(Response Code)は、HTTPプロトコルにおいて、サーバがクライアントに 返す応答のステータスを⽰す3桁の数字。クライアントがリクエストを送信した後、サーバは そのリクエストに対して適切なレスポンスコードを付与して返す。 レスポンスコードは、リクエストが成功したかどうか、エラーが発⽣したか、リダイレクトが ⾏われたかなど、さまざまな状態を表現する。以下は⼀般的なレスポンスコードの範囲とその 意味
1xx: インフォメーショナル(情報提供) 2xx: 成功 3xx: リダイレクト 4xx: クライアントエラー 5xx: サーバーエラー 具体的なレスポンスコードには、200 OK(成功)、404 Not Found(⾒つからない)、500 セッションとCookie HTTPは本来ステートレス(状態を管理しない)なプロトコルであるが、Webアプリケーションでの 状態管理を実現するためにセッションやクッキーといった仕組みが使⽤される セッションは、サーバー側でクライアントごとに状態を管理するための仕組み。セッションIDがク ライアントによって送信され、サーバーはそのセッションIDを使ってクライアントのセッションを 特定する。セッションにはサーバー上にデータを保存するためのメモリやデータベースが利⽤され ることが⼀般的 クッキーは、サーバーがクライアントのブラウザに保存する情報。サーバーはレスポンスヘッダに Set-Cookieヘッダを含めることで、クライアントにクッキーを送信する。その後、クライアントは リクエストごとにCookieヘッダを含めてサーバーに送信する。クッキーには期限を設けることがで き、有効期間内はクライアントがログアウトせずに再訪問した際にセッションの継続や認証情報の 保持が可能 セッション クッキー
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 ページ インメモリDB No SQL DB 通常のデータベースはディスク上に保存されており、ファイル形式(バイナリ)でデータを格 納するが、これに対して、インメモリデータベースはデータをメモリ上に保持し、ディスクへ の読み書きが不要なため、⾼速な処理が可能となる。それにより、応答速度が向上する利点が ある反⾯、障害発⽣時の対応の考慮が必要(メモリは永続的なデータ保持はできない)になる。
セッションの管理等で使われることが多い NoSQLは、従来のリレーショナルデータベース(SQLデータベース)に代わる新しいデータ ベースのアプローチを指し、NoSQLデータベースは、データの柔軟性やスケーラビリティの要 求に応えるために開発された。従来のリレーショナルデータベースはスキーマに厳密に従う必 要があり、データベースの変更やスケールアップに制約があったが、NoSQLデータベースは柔 軟なデータモデルを提供し、⼤規模なデータセットや分散環境における処理を効率的に⾏うこ とができる。