REST WebAPI サービス設計(Udemy)
問題一覧
1
分散型システムにおける設計ルール 1.サーバクライアント 2.ステートレス 3.キャッシュ制御 4.統一インターフェイス 5.階層化システム 6.コードオンデマンド
2
・サーバがセッション情報などの状態を保持しないという意味 ・クライアントのアプリケーション状態をサーバで管理しない
3
HTTPメソッドを8つに限定してクライアントとサーバの実装の独立性を向上する
4
・短く入力しやすい(冗長なパスを含まない) ・人が読んで理解できる。できるだけ省略しない ・大文字小文字が混在していない(すべて小文字で表現する) ・単語はハイフンでつなげる(ただしURLのパス等で分割することも検討すべし) ・単語は複数形を利用する ・エンコードを必要とする文字を使わない(要するに日本語を使わない) ・サーバ側のアーキテクチャを使用しない(.php等)は利用しない ・改造しやすいこと(システムの依存の設計をしない) ・ルールが統一されている
5
・一意なリソースを表す⇒パスパラメータ ・省略可能かどうか⇒クエリパラメータ
6
100:サーバがリクエストの最初の部分を受け取り、サーバから拒否されていないことを示す 101:プロトコルの切り替え要求を示す
7
200:リクエストの成功を示す。本文にデータが含まれる。 201:リクエストが成功を示す。ヘッダーのLocationに新しいリソースへのURLを含む 202:非同期ジョブを受け付けたことを示す。実際の処理結果は別途受け取る。 204:リクエストは成功したがレスポンスデータがないことを示す。クライアント側のビューを変更する必要がないことを示す
8
400:その他エラー 401:認証されていない 403:リソースに対するアクセスが許可されていないこと(認可されていない) 404:リソースが存在しないことを示す 409:リソースが競合されている 429:アクセス回数が制限回数を超えたため処理不可
9
500:サーバサイドのサプリケーションエラー 501:サーバが使用できない
10
【成功】 200 OK 304 Not Modified 【失敗】 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 429 Too Many Request 500 Internal Server Error 503 Server UnAvailable
11
【成功】 200 OK 201 Created 202 Accepted 【失敗】 400 Bad Request 401 Unauthorized 403 Forbidden 409 Conflict 429 Too Many Request 500 Internal Server Error 503 Server UnAvailable
12
・エンベロープは使用しない(ヘッダー情報と被るので) ※適切なHTTPステータスを返却する
13
・ページネーションをサポートする情報を返却する ※次をどこから取得するのか。キーとなる情報を返却する
14
JSONのオブジェクトはフラットにする
15
RFC3339(W3C-DTF)
16
パスに入れる クエリに入れる ヘッダに入れる
17
メジャー:後方互換しない修正 マイナー:後方互換する機能追加 パッチ:後方互換するバグ修正 メジャーバージョンのみ利用するのがおすすめ。 マイナーやパッチを付けてしまうと管理工数がおおい
18
認証は本人特定 認可はアクセス制御
19
OAuthとは、複数のWebサービスを連携して動作させるために使われる仕組みです。 通常、Webサービスを利用するためは、個別にユーザーIDとパスワードを入力してユーザーを認証する必要がありますが、OAuthを利用することで、IDやパスワードを入力することなく、アプリケーション間の連動ができるのです。
20
OAuth 2.0 認可プロセスを拡張し, 認証目的で利用できるようにしたもの Authと異なるところはアクセストークンの他IDトークンも返却される(JWTで)
21
API通信における、時間あたりのアクセス制限のこと
22
時間枠を固定にするアクセス制限のこと。とたえば10分に30回のアクセスを許可する場合は、10:00~10:30で30回、10:30~10:40で30回と定義する 問題点はFixed Windowの境界付近で大量のアクセスが来ると時間帯でみると実質的に2倍のアクセスを許容することになる
23
過去N分間のログの件数でカウントして、その件数でカウントする 問題点は過去ログを大量に保存する必要がある。
24
Sliding logとFixed Windowのいいところどり リクエストがあった過去M分間の比率を算出する Sliding logとFixed Windowのいいところどり ※画像参照。値をイメージするとわかりやすい
25
悪意あるユーザが正規のサイトに不正なスクリプトを挿入することで、正規ユーザの情報を不正に引き出したりする 【対策】 レスポンスヘッダー追加
26
本来拒否しなければならないアクセス元(許可しないアクセス元)からくるリクエストを処理してしまう問題 【詳細】 悪意あるユーザがトラップサイトを作成 善良なユーザをトラップサイトに誘導 トラップサイトから正規のサイトにリクエスト 【対策】 許可しないアクセス元からリクエストの拒否(X-API-KeyやAuthentiation(ユーザ単位)で実行可否判断) 攻撃者に推測されにくいトークンの発行
27
SSL…安全に通信を行うためのプロトコル(2015年廃止) TLS…安全に通信を行うためのプロトコル(SSLの後継) HTTPS…HTTP+SSL/TLS
Web技術の基本
Web技術の基本
ユーザ名非公開 · 18問 · 2年前Web技術の基本
Web技術の基本
18問 • 2年前Linuxコマンド
Linuxコマンド
ユーザ名非公開 · 14問 · 2年前Linuxコマンド
Linuxコマンド
14問 • 2年前Python
Python
ユーザ名非公開 · 69問 · 2年前Python
Python
69問 • 2年前スケール①
スケール①
ユーザ名非公開 · 108問 · 1年前スケール①
スケール①
108問 • 1年前スケール①
スケール①
ユーザ名非公開 · 108問 · 1年前スケール①
スケール①
108問 • 1年前コードヴォイシング
コードヴォイシング
ユーザ名非公開 · 84問 · 1年前コードヴォイシング
コードヴォイシング
84問 • 1年前問題一覧
1
分散型システムにおける設計ルール 1.サーバクライアント 2.ステートレス 3.キャッシュ制御 4.統一インターフェイス 5.階層化システム 6.コードオンデマンド
2
・サーバがセッション情報などの状態を保持しないという意味 ・クライアントのアプリケーション状態をサーバで管理しない
3
HTTPメソッドを8つに限定してクライアントとサーバの実装の独立性を向上する
4
・短く入力しやすい(冗長なパスを含まない) ・人が読んで理解できる。できるだけ省略しない ・大文字小文字が混在していない(すべて小文字で表現する) ・単語はハイフンでつなげる(ただしURLのパス等で分割することも検討すべし) ・単語は複数形を利用する ・エンコードを必要とする文字を使わない(要するに日本語を使わない) ・サーバ側のアーキテクチャを使用しない(.php等)は利用しない ・改造しやすいこと(システムの依存の設計をしない) ・ルールが統一されている
5
・一意なリソースを表す⇒パスパラメータ ・省略可能かどうか⇒クエリパラメータ
6
100:サーバがリクエストの最初の部分を受け取り、サーバから拒否されていないことを示す 101:プロトコルの切り替え要求を示す
7
200:リクエストの成功を示す。本文にデータが含まれる。 201:リクエストが成功を示す。ヘッダーのLocationに新しいリソースへのURLを含む 202:非同期ジョブを受け付けたことを示す。実際の処理結果は別途受け取る。 204:リクエストは成功したがレスポンスデータがないことを示す。クライアント側のビューを変更する必要がないことを示す
8
400:その他エラー 401:認証されていない 403:リソースに対するアクセスが許可されていないこと(認可されていない) 404:リソースが存在しないことを示す 409:リソースが競合されている 429:アクセス回数が制限回数を超えたため処理不可
9
500:サーバサイドのサプリケーションエラー 501:サーバが使用できない
10
【成功】 200 OK 304 Not Modified 【失敗】 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 429 Too Many Request 500 Internal Server Error 503 Server UnAvailable
11
【成功】 200 OK 201 Created 202 Accepted 【失敗】 400 Bad Request 401 Unauthorized 403 Forbidden 409 Conflict 429 Too Many Request 500 Internal Server Error 503 Server UnAvailable
12
・エンベロープは使用しない(ヘッダー情報と被るので) ※適切なHTTPステータスを返却する
13
・ページネーションをサポートする情報を返却する ※次をどこから取得するのか。キーとなる情報を返却する
14
JSONのオブジェクトはフラットにする
15
RFC3339(W3C-DTF)
16
パスに入れる クエリに入れる ヘッダに入れる
17
メジャー:後方互換しない修正 マイナー:後方互換する機能追加 パッチ:後方互換するバグ修正 メジャーバージョンのみ利用するのがおすすめ。 マイナーやパッチを付けてしまうと管理工数がおおい
18
認証は本人特定 認可はアクセス制御
19
OAuthとは、複数のWebサービスを連携して動作させるために使われる仕組みです。 通常、Webサービスを利用するためは、個別にユーザーIDとパスワードを入力してユーザーを認証する必要がありますが、OAuthを利用することで、IDやパスワードを入力することなく、アプリケーション間の連動ができるのです。
20
OAuth 2.0 認可プロセスを拡張し, 認証目的で利用できるようにしたもの Authと異なるところはアクセストークンの他IDトークンも返却される(JWTで)
21
API通信における、時間あたりのアクセス制限のこと
22
時間枠を固定にするアクセス制限のこと。とたえば10分に30回のアクセスを許可する場合は、10:00~10:30で30回、10:30~10:40で30回と定義する 問題点はFixed Windowの境界付近で大量のアクセスが来ると時間帯でみると実質的に2倍のアクセスを許容することになる
23
過去N分間のログの件数でカウントして、その件数でカウントする 問題点は過去ログを大量に保存する必要がある。
24
Sliding logとFixed Windowのいいところどり リクエストがあった過去M分間の比率を算出する Sliding logとFixed Windowのいいところどり ※画像参照。値をイメージするとわかりやすい
25
悪意あるユーザが正規のサイトに不正なスクリプトを挿入することで、正規ユーザの情報を不正に引き出したりする 【対策】 レスポンスヘッダー追加
26
本来拒否しなければならないアクセス元(許可しないアクセス元)からくるリクエストを処理してしまう問題 【詳細】 悪意あるユーザがトラップサイトを作成 善良なユーザをトラップサイトに誘導 トラップサイトから正規のサイトにリクエスト 【対策】 許可しないアクセス元からリクエストの拒否(X-API-KeyやAuthentiation(ユーザ単位)で実行可否判断) 攻撃者に推測されにくいトークンの発行
27
SSL…安全に通信を行うためのプロトコル(2015年廃止) TLS…安全に通信を行うためのプロトコル(SSLの後継) HTTPS…HTTP+SSL/TLS