非開発者のための IT 常識 #2 API とは何か — サービス同士が会話する約束

IT知識
読了 6分

前回の記事で、ウェブサイトはフロントエンド、バックエンド、データベースという三つの層からできていて、この三つの層がユーザーの行動一つごとに絶えず互いに会話する、とお話ししました。そのうえで、一つを次回に持ち越していました。その会話がどんな約束の上で行われるのか、それがまさに API です。

API は、開発者が一日に何度も使う単語です。「そのデータは API で受け取ります」「API が返ってきません」「その機能は外部 API 連携が必要なので、少し時間がかかります」といった言葉を聞いたことがあるはずです。今回の記事では、この API が正確に何なのか、そしてなぜ最近のサービスは API なしでは、ほとんど回らないのかを見ていきます。

今回のシリーズは 非開発者のための IT 常識 の全 5 編で構成されます。

  • #1 ウェブサイトは何でできているのか — フロントエンド・バックエンド・データベース
  • #2 API とは何か — サービス同士が会話する約束 ← この記事
  • #3 サーバー、クラウド、そしてデプロイ
  • #4 バグ、ホットフィックス、ロールバック — 開発者が障害に対応する方法
  • #5 Git とバージョン管理 — 複数人で一つのコードを直す方法

API は決まった方法でやり取りする約束です #

前回の記事で、バックエンドをレストランの厨房に例えました。お客様は厨房に直接入りません。メニューを見て、スタッフに決まった方法で注文すれば、決まった形で料理が出てきます。お客様は厨房がどのように回っているかを知らなくてかまいません。メニューとスタッフという決まった窓口さえ通せば、望むものを受け取れます。

API は、まさにこのメニューやスタッフのようなものです。「こう要求すれば、こういう形式で返してくれる」という約束であり、その約束に従ってやり取りする窓口です。フロントエンドはバックエンドの内部事情を知らなくても、API という窓口を通せば、必要なデータを受け取れます。

API は Application Programming Interface の略です。単語は難しく聞こえますが、ほどいてみると、プログラム同士が決まった方法でやり取りするための窓口という意味です。人がメニューを通して厨房とやり取りするように、プログラムも API を通して別のプログラムとやり取りします。

リクエストとレスポンスで成り立ちます #

API を通じた会話は、リクエストとレスポンスという二つの段階で成り立ちます。

天気アプリを例に挙げてみます。アプリの画面（フロントエンド）が「ソウルの今の天気を教えてほしい」とバックエンドにリクエストします。このときリクエストには、何を望むのかとあわせて、必要な情報（どの都市か）を入れます。バックエンドはそのリクエストを受け取ってデータを探したうえで、約束された形式でレスポンスを返します。たとえば「都市はソウル、気温は 21 度、状態は晴れ」のような形です。

このとき、レスポンスがどんな形でもよいわけではなく、あらかじめ約束された形式で返ってくるという点が重要です。開発では主に JSON という形式を使います。人が見ても「名前は何、値は何」と整理された形だと考えればよいです。形式が決まっているので、フロントエンドは受け取ったレスポンスから気温の値を取り出し、そのまま画面に表示できます。

内部でも使い、外部サービスも取り込みます #

API は、一つのサービスの中だけで使うものではありません。大きく二つに分けて見ることができます。

一つ目は内部 API です。一つのサービスのフロントエンドとバックエンドがやり取りする窓口です。前回の記事で見たログインの流れが、これにあたります。

二つ目は外部 API です。他の会社やサービスが用意した機能を、API という窓口で取り込んで使うものです。私たちが毎日使うアプリには、こうした外部 API がたくさんあります。画面に地図を表示する機能はたいてい地図 API を組み込み、決済は決済代行会社の API を使い、カカオやグーグルで手軽にログインする機能は、その会社が提供するログイン API を連携したものです。テキストメッセージの送信、為替の照会、翻訳のような機能も同じです。

おかげで、すべての機能を自分で作る必要がありません。よくできた外部機能を API で組み込めば、サービスを素早く形にできます。最近のアプリは、複数の API を組み合わせて作られたものに近いです。

なぜ非開発者が知ると仕事が楽になるのか #

API を理解すると、実務で開発者との会話が一段とスムーズになります。

  • 機能リクエストの重さを推し量れます。 「ここに地図を表示してください」という依頼は、地図 API を連携しなければならない仕事であり、その分だけ時間とコストがかかります。外部機能を新しく組み込む仕事なのか、すでにあるデータを見せる仕事なのかを区別できれば、スケジュール感がつかめます。
  • 問題のあるところを絞り込めます。 「地図が表示されません」「決済が止まりました」といった状況で、自分たちのサービスの問題なのか、連携した外部 API の問題なのかを、あわせて疑えます。
  • 企画段階でよい質問を投げかけられます。 「この機能、提供されている API はありますか。それとも自分たちで作らないといけませんか」という質問一つが、スケジュールとコストを大きく変えます。

特に外部 API は、ほとんどが使用量に応じて料金がかかります。ユーザーが増えて呼び出しが多くなれば、その分コストも増えます。この点を知っておけば、サービスが大きくなったときのコスト構造を、あらかじめ見積もれます。

API にもルールと限界があります #

API は、誰もが好き勝手に使える窓口ではありません。いくつかのルールが付いてきます。

まずは認証です。外部 API はたいてい API キーという一種の入館証を発行します。このキーで身元を確認し、許可されたユーザーだけが窓口を利用できるようにします。

次は呼び出しの上限です。よく rate limit と呼ばれるもので、一定時間に決まった回数だけリクエストできるように制限します。この上限を超えると、しばらくリクエストが止められます。一つのサービスの暴走が、他のユーザーにまで影響しないようにする仕組みです。

最後は、依存に伴うリスクです。外部 API に頼るということは、その提供者の方針に従うという意味でもあります。提供者がレスポンスの形式を変えたり、料金を上げたり、サービスを終了したりすると、その影響をそのまま受けます。便利さの裏側には、こうした依存があることも、あわせて知っておくとよいです。

まとめ #

この記事では、API が何なのかを見てきました。

  • API は、プログラム同士が決まった方法でリクエストし、決まった形式でレスポンスを受け取る約束であり、窓口です。
  • 会話は リクエストとレスポンス で成り立ち、レスポンスは主に JSON のような約束された形式で返ってきます。
  • 一つのサービスの中をつなぐ 内部 API と、他社の機能を取り込んで使う 外部 API があります。
  • API には認証、呼び出しの上限、依存リスクといったルールと限界が付いてきます。

前回の記事で見たバックエンド、そして今回の記事で見た API は、どちらもユーザーの目に見えないところで動いています。それでは、このバックエンドと API は、実際にどこで実行されているのでしょうか。次の記事では サーバー、クラウド、そしてデプロイ が何なのかを見ていきます。

X