応用情報技術者 2017年 秋期 午後 問04

解答の論理構成

1. 【問題文】のユーザ登録シナリオでは、アプリが受け取る情報として
   　　‐「愛称」
   　　‐「ユーザID」
   　　‐「パスワード」
   　　‐「メールアドレス」
   　が列挙されています（「アプリは、愛称、メールアドレス、ユーザID、パスワードをスマホ内に保存する。」）。
2. 健康機器で“ユーザ参照”WebAPIを呼び出すには、以下が必要です。
   　(1) URI内の {userId}: 「URIテンプレートは、https://api.example.co.jp/{version}/users/{userld}/{valueType}」とあり、ユーザIDが必須。
   　(2) 認証ヘッダ: 「②ユーザ認証は、HTTPリクエストヘッダのX-Authorizationヘッダフィールドで、“ユーザID：パスワード”をBASE64エンコードしたものを設定する方式」とあるため、ユーザIDとパスワードが必要。
3. 健康機器の画面で利用者が自分を識別できるようにするには、計測シナリオの「ディスプレイに表示される愛称を確認して、計測対象者を選択する。」との記述から「愛称」が必要。
4. 上記により、健康機器へ送る「①必要なユーザ情報」は
   　　愛称・ユーザID・パスワード
   　であると結論付けられます。

誤りやすいポイント

• 「メールアドレス」も送ると考えてしまう
  → メール送信はWebAPI側の処理であり、機器で利用しない。
• 認証に必要なのは「ユーザID」のみと思い込む
  → X-Authorizationヘッダには「ユーザID：パスワード」をセットするので両方必須。
• 「愛称」を忘れる
  → ディスプレイ表示で利用者が自分を選択するために必須。

FAQ

解答の論理構成

1. 本文では、認証方式として
   「HTTPリクエストヘッダのX-Authorizationヘッダフィールドで、“ユーザID：パスワード”をBASE64エンコードしたものを設定する方式」
   と明示しています。
2. BASE64は可逆変換であり暗号化ではありません。したがって平文同等の認証情報がネットワーク上を流れる危険があります。
3. そこで設計方針欄には
   「WebAPIへのアクセスは、全てHTTPSを用いて行う。」
   とあります。HTTPSによって通信経路をTLSで暗号化し、盗聴・改ざんを防止できます。
4. よって、下線②の方式を安全に運用するには、この設計方針を必須と判断でき、理由は「HTTPでは盗聴される」ためです。

誤りやすいポイント

• BASE64を暗号化と勘違いし、追加の保護が要らないと誤解する。
• 「TLSは重いから内部ネットワークなら不要」と判断してしまう。家庭内Wi-Fiでも盗聴リスクは残るため注意。
• 設計方針を「認証強化」や「トークン制」に置き換えてしまい、本文中の字句を守れず減点される。

FAQ

解答の論理構成

1. 【問題文】のユースケース「計測」では、 「健康機器は、計測した1件分の計測値種別、計測日時、計測値を“計測データ登録”WebAPIに渡す。」
   と明記されています。
2. 表3のaの行は、HTTPメソッドが「POST」でリクエストボディにg（計測値種別など）が送られる登録系のAPIであり、ユースケース中で呼び出される登録用APIに合致します。
3. したがって、aに入るAPI名はユースケースと設計方針の両方に合わせて「計測データ登録」と決定できます。

誤りやすいポイント

• API名を英語表記（例：uploadMeasurement）で考えてしまう。設問は表3の他項目と同様、日本語名で統一されています。
• 「ユーザ登録」「ユーザ削除」など他のCRUD操作と混同し、計測データ参照やアップデートと取り違える。POSTメソッド＋計測値情報の送信という条件が登録であることを示しています。
• 表3のURIやHTTPメソッドに着目せず、ユースケースの記述だけを頼りにしてしまうと、似た表現のAPI名を選んでしまうリスクがあります。

FAQ

解答の導き方

1. 計測データ参照（設問[c]）の検討

• 表2の「計測データ」テーブルには「ユーザID, 計測値種別, 計測日時, 計測値」とあるため、計測データは特定のユーザに紐付くデータです。したがってURIはユーザを特定する要素（{userId}）を含むべきです。
• URIテンプレートに{version}→v1、{valueType}→weightsを当てはめると、計測データ（weights）を参照するURIは
  https://api.example.co.jp/v1/users/{userId}/weights
  となり、解答群のウ（https://api.example.co.jp/v1/users/{userId}/weights）と一致します。
• 選択肢エ（https://api.example.co.jp/v1/weights）はユーザ文脈が欠けており、表の構造や「リソースの関係性が一目で分かるようにする」という設計方針に反します。

1. ユーザ参照（設問[b]）の検討

• 表2の「ユーザ」テーブルに「ユーザID, パスワード, 愛称, メールアドレス, 登録日時」とあり、ユーザ参照は特定のユーザIDに対する操作です。
• URIテンプレートに{version}→v1を当てはめ、特定ユーザを示す{userId}を含めれば、ユーザ取得のURIは
  https://api.example.co.jp/v1/users/{userId}
  となり、解答群のイ（https://api.example.co.jp/v1/users/{userId}）と一致します。
• 選択肢ア（https://api.example.co.jp/v1/users）はコレクション（ユーザの作成や一覧取得）に対応するエンドポイントで、単一ユーザの参照には不適切です。

誤りやすいポイント

• /usersと /users/{userId} を混同する：/usersはコレクション、/users/{userId} は単一リソースです。
• valueType（weights）をルートに置く（/weights）ミス：計測データはユーザに紐付くため、/users/{userId}/weightsの形が正しいです。
• バージョン番号を忘れる：テンプレートに {version} があるのでv1を必ず含めます。
• HTTPメソッドを誤る：設計方針で「CRUD…をそれぞれHTTPメソッドのPOST, GET, PUT, DELETEで提供する」とあるため、参照はGETです。
• 認証の扱いでの誤解：設計では「ユーザ認証は、HTTPリクエストヘッダのX-Authorizationヘッダフィールドで、“ユーザID：パスワード”をBASE64エンコードしたものを設定する方式」とありますが、BASE64は可逆のエンコードで暗号化ではありません。認証情報の機密性はHTTPSに依存するため、実務ではトークン方式やOAuth2等の検討が必要です。

FAQ

解答の論理構成

1. 設計方針の確認
   問題文には次の記述があります。
   「アクセス対象へのCRUD（Create, Read, Update, Delete）の操作を、それぞれHTTPメソッドのPOST, GET, PUT, DELETEで提供する。」
   ここから、 • Create → POST
   • Read → GET
   • Update → PUT
   • Delete → DELETE
   という対応が確定します。
2. d の判断（ユーザ削除）
   表3の API 名は「ユーザ削除」です。削除操作は CRUD の Delete に該当するため、HTTP メソッドは「DELETE」となります。
3. e の判断（計測データ参照）
   表3のAPI名は「計測データ参照」です。参照操作はCRUDのReadに該当するため、HTTPメソッドは「GET」となります。
4. 結論
   • d：DELETE
   • e：GET

誤りやすいポイント

• 「PUT＝更新」の対応を忘れ、削除でもPUTを選択してしまう。
• 「参照」に対してPOSTを選ぶなど、CRUDとHTTPメソッドの基本対応を混同する。
• RESTではURIに動詞を入れない方針（問題文中「deleteUserのように…ではなく…複数形の名詞で」）を見落とし、URIだけで判断しようとして迷う。

FAQ

解答の論理構成

1. f の検討
   • 【問題文】には、WebAPI の設計方針として「アクセス対象へのCRUD（Create, Read, Update, Delete）の操作を、それぞれHTTPメソッドのPOST, GET, PUT, DELETEで提供する。」とあります。
   • 表3で “ユーザ参照” はHTTPメソッドがGETです。通常RESTではGETリクエストにボディを付けず、取得対象はURIで指定します。
   • したがって “f” には何も送らないことを示す “－” が入ります。
2. g の検討
   • “計測” ユースケースでは「健康機器は、計測した1件分の計測値種別、計測日時、計測値を“計測データ登録”WebAPIに渡す。」と記述されています。
   • 表3ではURIで計測値種別（体重計の場合は “weights”）を指定しているため、リクエストボディで改めて送るのは残りの「計測日時」と「計測値」です。
   • よって “g” には “計測日時、計測値” が入ります。

誤りやすいポイント

• GETにJSONボディを付けても動作する実装は存在しますが、RESTの慣習に従うとボディは付けないのが原則です。試験では原則論で判断します。
• “g” に「計測値種別」を含めてしまう誤答が頻発します。計測値種別はURIで指定済みであることを見落とさないよう注意が必要です。
• CRUDとHTTPメソッドの対応を混同すると f も g も誤る危険があります。

FAQ

解答の論理構成

1. 【問題文】では“ユーザ登録”WebAPIのリクエストとして「愛称、メールアドレス」を必須項目と定義しています。
   引用：
   ・表1「利用者は、アプリの“ユーザ登録”画面で、登録する利用者の愛称（中略）とメールアドレスを入力する。」
   ・表3「ユーザ登録　リクエストのボディ部：愛称、メールアドレス」
2. 設計方針で、不正なパラメタに対するレスポンスを明示しています。
   引用：
   「WebAPIの実行結果のステータスは、標準的なHTTPステータスを使用する。
   200：OK
   400：不正なパラメタ」
3. 提示されたリクエスト例は {"nickname": ""} であり、必須である「愛称」が空文字、さらに「メールアドレス」が欠落しています。これは【問題文】の定義と矛盾するため「不正なパラメタ」と判断できます。
4. 従って設計方針の規定どおり、HTTPステータスコード「400」を返すのが正しい動作となります。

誤りやすいポイント

• 200（OK）を返してしまう
  入力チェックを実装し忘れ、「空でも登録できる」と誤解してしまうケース。
• 401（認証失敗）と混同
  今回はリクエストパラメータの問題であり、ユーザ認証自体は行えています。
• 404（データが存在しない）を選択
  登録フェーズなので「存在しないデータ」は論点外です。

FAQ