基本情報のAPIを要求・応答と身近な連携の例で理解する

基本情報のAPIは、プログラムが別のプログラムの機能やデータを利用するための取り決めです。人が画面で操作すること、ネットワークにつながること、データをJSONで表すこととは、それぞれ役割が違います。

意味だけ覚えても、「OSの機能を呼び出す」「外部のサービスと連携する」といった問題文になると迷いやすいですよね。この記事では架空の図書貸出サービスを例に、誰が、どの機能へ、何を渡して、何を受け取るのかを追います。後半では読み取りと更新、認証と認可、通信失敗時の判断を自作問題で確認します。

この記事のポイント

APIと画面・通信プロトコル・データ形式の役割を区別できる
図書貸出の例で要求と応答に含める情報を整理できる
HTTPメソッドと処理結果を別々に読める
認証・認可と更新の再実行で注意する条件を説明できる

無料

基本情報技術者試験過去問アプリ

本番形式で繰り返し解ける。スキマ時間に1問から

2,000問以上収録

無料で過去問を解く

基本情報のAPIの仕組みと役割

接点で何を決めるのか

APIはApplication Programming Interfaceの略です。ソフトウェア同士の接点であり、利用できる操作、入力の形式、返される値、エラーの扱いなどを定めます。内部の処理をすべて公開しなくても、呼び出す側は決められた方法で機能を利用できます。

例えば図書館の貸出状況を調べるアプリが、管理システムへ本の識別番号を渡すとします。管理システムは、その本を貸出可能か、貸出中かという結果を返します。アプリが知る必要があるのは、番号の渡し方と結果の読み方です。管理システムの中で何個の表を使っているかまで知る必要はありません。

ただし「中身を知らなくてよい」は「仕様を読まなくてよい」という意味ではありません。番号が文字列なのか整数なのか、存在しない番号を渡すとどうなるのか、利用回数に上限があるのかなど、境界の条件は確認します。入力と出力の約束が合わなければ、両方のプログラムが正常でも連携は成立しません。

IPAも、APIをアプリケーション同士の接点として説明しています。まずは「プログラム間の取り決め」という軸を持ち、個別の技術名はその後に関連付けると整理しやすくなります。APIの基本的な説明はIPAの技術解説でも確認できます。

UIやプロトコルとの違い

UIは、利用者がシステムを扱うための接点です。画面の検索欄に書名を入力して検索ボタンを押すのは、人とソフトウェアのやり取りです。その画面を動かすプログラムが別の検索サービスを呼び出すところでは、APIが使われます。同じ検索機能でも、接点の相手が違います。

通信プロトコルは、通信相手とのやり取りに使う規則です。Web APIの呼び出しにHTTPを使う場合、HTTPは要求と応答を運ぶための共通の土台になります。その上で「どのパスへ、どの項目を送り、どんな本の情報を返すか」を個別のAPI仕様が決めます。

JSONやXMLはデータを表現する形式です。貸出状況をJSONで返すAPIも、XMLで返すAPIも考えられます。データ形式が同じでも、項目名や意味が違えばそのまま接続できません。「JSONを使っているから同じAPI」という判断はできないわけですね。

スクロールできます

用語	接点や規則の対象	図書貸出での例
UI	人とシステム	書名の入力欄と検索ボタン
API	プログラムと機能・データ	本の番号を渡して貸出状況を得る取り決め
HTTP	通信の要求と応答	要求メソッドや応答の状態を表す規則
JSON	データの表現形式	本の番号や貸出可否をキーと値で表す

問題文では、似た英略語を暗記するより「何と何の間の話か」を一度日本語に直してみてください。人が使う入口なのか、プログラムが使う入口なのか、データの書き方なのかが分かると、選択肢を絞れます。通信の層や役割があいまいなら、基本情報のネットワーク分野の整理もつなげて読むと理解しやすくなります。

OS・ライブラリとWebで考える

APIは外部のWebサービスだけにあるわけではありません。ファイルを開く、時刻を取得するなど、OSやライブラリの機能をプログラムから利用する場合にもAPIがあります。別のコンピュータへインターネット経由で送信することは、APIの必須条件ではありません。

ライブラリの関数を呼ぶ場面では、関数名、引数、戻り値などが接点の中心になります。例えば「文字列を渡すと、その長さを数値で返す」という約束があれば、呼び出す側は内部でどう数えているかを意識せず使えます。ただし、文字の数え方や空の入力への対応まで同じとは限らないので、仕様の範囲は確認が必要です。

Web APIでは、離れたサービスの機能をネットワーク越しに利用します。呼び出し先のURL、HTTPメソッド、ヘッダ、送信データなどが関係します。通信遅延やサービスの停止が起こり得るため、手元の単純な関数呼び出しと同じ感覚で、必ずすぐに結果が返ると考えないことも大切です。

ここでSDKとの違いも整理できます。SDKはソフトウェア開発を助ける道具のまとまりで、ライブラリやサンプルなどを含む場合があります。SDKが内部でAPIを呼び出すことはありますが、APIという接点そのものと、開発道具一式は別です。試験では「機能の利用方法を定めた接点」という説明に注目しましょう。

要求と応答を一組で読む

図書貸出サービスに「本の状態を取得するAPI」があるとします。次のパスや項目名は仕組みを説明するための架空の例で、実在サービスの操作手順ではありません。呼び出す側は、本の番号42を調べるためにGET /books/42という要求を送るものとします。

この場合、/books/42は調べる対象を示し、GETは読み取りの意図を示します。応答では「対象の本が見つかり、貸出可能だった」といった内容を受け取ります。返るデータにbookIdとavailableという項目があるなら、前者が本の識別番号、後者が貸出可否という仕様を双方が共有します。

本の番号を知らない検索なら、書名などの検索条件をクエリパラメータで渡す設計も考えられます。一方、新たな貸出記録を登録するなら、利用者と本を特定する情報が必要になります。同じサービスのAPIでも、操作が違えば必要な入力と返す結果は変わります。

応答を読むときは、HTTPの状態と、本文に入る業務上の意味を分けます。通信として応答が返っても、「希望の本は貸出中」という回答はあり得ます。逆に通信が途中で途切れた場合は、業務処理が行われていないと即断できません。この区別は、後半の更新の再実行で特に重要になります。

仕様を隠すことと変更の影響

APIの利点の一つは、接点を保ちながら内部の実装を変えやすくすることです。図書情報の保存先を別のデータベースへ移しても、同じ入力に対して同じ意味の結果を返す約束を保てれば、呼び出すアプリの変更を抑えられます。既存の機能を再利用できるので、利用側が同じ処理を一から実装する負担も減らせます。

ただし、APIがあれば変更の影響が必ずなくなるわけではありません。結果の項目名を変えたり、数字だった識別子を違う形式へ変えたりすると、呼び出す側が正しく読めなくなる場合があります。入力・出力の意味やエラー条件を保つことまで含めて、互換性を考える必要があります。

例えば貸出可否をtrueまたはfalseで返していたところへ、「貸出可」「貸出中」という文字列を返すように変えたらどうでしょうか。人には理解できても、真偽値として判定していたプログラムには別の型です。見た目に分かりやすくする変更でも、既存の契約を壊す可能性があります。

また、外部APIの利用には提供側への依存もあります。応答が遅い、利用条件が変わる、提供が終わるといった影響を受け得ます。導入の問題では「連携できる」という利点だけでなく、機能・利用条件・停止時の対応を確認するという判断までつなげると、選択肢を読み違えにくくなります。

基本情報のAPIを例題で理解する

HTTPメソッドと結果を分ける

HTTPを使うAPIでは、メソッドが要求の意味を表します。代表的にはGETが取得、POSTが対象にデータを送って処理を求める操作、PUTが指定した対象の表現の作成または置換、DELETEが削除に対応します。個別のサービスで利用できる操作と送信形式は、そのAPI仕様で確認します。

POSTを「常に新規登録だけ」と覚えると、仕様によっては混乱します。計算などの処理を依頼する用途もあるからです。またGETは、利用側がサーバの状態変更を求めない安全なメソッドです。サーバでアクセスの記録が増えることと、利用者が本の貸出を登録することは区別します。

応答の状態コードは別の情報です。200番台は成功、400番台はクライアント側の要求に関する問題、500番台はサーバ側の処理に関する問題を表す分類です。例えば404なら対象が見つからないこと、403ならアクセスが拒否されたことなど、具体的な意味まで読む必要があります。

「GETを送ったから必ずデータが返る」「200が返ったから在庫がある」とは言えません。要求した操作、HTTPの結果、業務データの内容を順に確認します。メソッドの意味はMDNのHTTPリクエストメソッド、状態の分類はHTTPレスポンスステータスコードで確認できます。

スクロールできます

読む場所	確認すること	取り違えやすい点
要求のメソッド	何を求めたか	GETでも対象が見つからない場合がある
応答の状態コード	HTTPでどんな結果になったか	成功コードだけで業務条件まで決まらない
応答の本文	何のデータや業務結果が返ったか	貸出中という回答も有用な取得結果になる

認証と認可を区別する

認証は、アクセスしてきた相手が誰かを確認することです。認可は、その相手にどの操作を許すかを決めることです。ログインできた利用者でも、他人の貸出記録を変更してよいとは限りません。本人確認ができることと、すべての情報へアクセスできることは別です。

図書貸出の例なら、利用者本人に自分の貸出一覧の閲覧を許し、管理者だけに貸出記録の修正を許す設計が考えられます。画面で修正ボタンを隠すだけでは不十分です。別のプログラムから同じAPIへ要求を送られても、サーバ側で対象と操作の権限を確かめる必要があります。

APIキーやトークンは、呼び出し元の識別やアクセスの制御に使われることがあります。ただし、キーを持っていれば常に本人のすべての権限を証明できるわけではありません。何を識別する値なのか、どの範囲へ使えるかは方式と仕様次第です。公開する画面や共有する資料に秘密の値を埋め込まないことも基本になります。

HTTPSによる通信路の保護も、認可の代わりにはなりません。通信途中の盗聴や改ざんに備えることと、接続した利用者へ特定の記録の変更を許すことは、守っている対象が違います。暗号やTLSとの関係を整理したい場合は、基本情報の暗号化とTLSの違いも確認してみてください。

失敗時に更新を繰り返さない

貸出登録を要求した直後に通信が切れ、結果を受け取れなかったとします。この時点では、要求が届かなかった場合と、登録は完了して応答だけ届かなかった場合の両方が考えられます。通信の失敗を、そのまま処理の失敗と同一視しないことが重要です。

確認せず同じ登録を送ると、設計によっては貸出記録が重複するかもしれません。読み取りを再試行することと、状態を変える操作を再試行することは同じではありません。結果不明なら、処理を識別する番号による照会など、サービスが用意した確認方法を先に使うのが基本の考え方です。

ここで関係するのが、同じ要求を繰り返しても意図した効果が一度の場合と同じになる「べき等性」です。HTTPではGET、PUT、DELETEなどがべき等な意味を持ちますが、毎回同じ応答本文や状態コードが返るという意味ではありません。例えば削除後の再要求では、対象がすでに存在しないと分かる応答になることがあります。

POSTは一般にべき等とは定義されません。ただし、個別APIが重複を防ぐ識別子などを提供する場合はあります。「POSTは何があっても再試行不可」「キーを付ければどのAPIでも安全」と単純化せず、APIの契約と確認方法を読みます。HTTPの安全性とべき等性の定義はIETFのRFC9110で確認できます。

自作問題で判断の根拠を確認

ここからは仕組みを確かめるための自作問題です。実際の試験問題の転載でも、出題を予想したものでもありません。用語を当てるだけで終わらず、どの条件が判断の根拠になったかも説明してみてください。

問題1。アプリがOSのファイル操作機能を、定められた関数名と引数で利用しています。インターネットを使っていないのでAPIではない、という説明は正しいでしょうか。答えは誤りです。APIはWeb APIだけを指さず、OSの機能を利用する接点も含むためです。通信の有無を必須条件にしないことがポイントです。

問題2。二つのサービスがどちらもJSONで応答します。それだけで入力と出力をそのまま連携できるでしょうか。答えは、できるとは限りません。JSONという形式が同じでも、項目名、値の型、単位、データの意味が一致するとは限らないからです。例えば同じ数値の100でも、本の番号なのか件数なのかで扱いが変わります。

問題3。利用者の本人確認に成功しました。そのため、ほかの利用者の貸出記録も変更できるようにしました。この判断は適切でしょうか。答えは不適切です。認証できたこととは別に、対象データと操作について認可する必要があります。「誰か分かった」と「何でもしてよい」を結び付けないことが根拠になります。

問題4。貸出登録の要求後にタイムアウトしました。同じ登録要求をすぐ再送すれば必ず安全でしょうか。答えは、必ず安全とは言えません。サーバ側では登録が済み、応答だけ失われた可能性があるからです。結果照会の手段や重複防止の契約を確認し、同じ業務処理が二重に成立しないかを考えます。

問題5。APIの内部のデータベース構成を変更しました。利用側が使う入力と応答の意味は保っています。アプリを必ず全面改修しなければならないでしょうか。答えは、必ず必要とは限りません。APIで定めた接点を保てるなら、内部変更の影響を抑えられるためです。ただし性能や利用条件など、別の影響がないことまで保証する説明にはしません。