「API連携」がどういうものかは、なんとなく掴めてきた。でも、求人票や技術記事を読んでいると、今度は「REST API」という言葉が当たり前のように出てきます。ただのAPIと、何が違うのでしょうか。
結論から言うと、REST APIは「APIの中でも、ある決まった作法にそって作られたもの」です。この記事では、APIそのものの説明はAPIとはにゆずり、ここではRESTという作法の中身、つまり「どんなルールでデータをやり取りするのか」に集中して解説します。
結論：REST APIは「Webの標準ルールに沿った、データのやり取りの作法」
REST APIを一言でいうと、「Webの標準的な仕組み(HTTP)に沿って、データを『リソース』として、決まったルールでやり取りするAPIの作法」です。
ここで出てくるHTTPとは、ふだんブラウザでサイトを開くときに裏側で使われている通信のルールのこと。REST APIは、この誰もが使っている仕組みをそのまま流用します。だから特別な仕組みを新しく覚えなくても、Webを触ったことがある人にとって理解しやすいのが特徴です。
大切なのは、RESTが「モノの数え方」と「操作の言い方」を統一している点です。次から、その中身を順番に見ていきます。
リソースという考え方：URLは「モノ」を表す
RESTでいちばん大事な考え方が「リソース」です。リソースとは、扱いたいデータのかたまり、つまり「モノ」のことだと思ってください。ユーザー、商品、記事。これらはすべてリソースです。
RESTでは、このリソースひとつひとつにURL(住所のようなもの)を割り当てます。たとえば次のように考えます。
/users… 「ユーザーたち」全体を表す住所/users/123… 「ID123番のユーザー」という特定の一人を表す住所
つまりURLは、動作ではなく「どのモノについて話しているか」を表す名札のような役割を持ちます。図書館で本を探すとき、棚の番号を見れば目当ての本にたどり着けるのと似ています。/users/123 と言えば、それだけで「あの人のデータ」を指し示せるわけです。
HTTPメソッドで操作を表す：同じ住所でも「動詞」で意味が変わる
では、そのモノに対して「取得したいのか、消したいのか」といった操作は、どう伝えるのでしょうか。RESTでは、これをHTTPメソッドという「動詞」で表します。主に使うのは次の4つです。
- GET … 取得する(データを見せて)
- POST … 作成する(新しく追加して)
- PUT・PATCH … 更新する(内容を書き換えて)
- DELETE … 削除する(消して)
おもしろいのは、URLが同じでも、この動詞が変われば意味がまるごと変わる点です。/users/123 という同じ住所に対して、GETなら「その人の情報を見せて」、DELETEなら「その人を消して」という別の依頼になります。
ステートレス：サーバは前のやり取りを覚えていない
RESTのもうひとつの特徴が「ステートレス」という性質です。むずかしそうな言葉ですが、意味はシンプルで、「サーバは前回のやり取りを覚えていない」ということです。
たとえば、行くたびに店員さんが自分の名前を忘れているお店を想像してみてください。不便に思えますが、その代わりに毎回きちんと「私はこういう者で、これがしたい」と伝えれば、注文はちゃんと通ります。RESTのサーバもこれと同じで、一回一回のリクエストに、必要な情報をすべて含めて送るのが前提です。
この性質があるため、「今アクセスしているのが誰なのか」も毎回伝える必要があります。そこで登場するのが、本人であることを示す通行証のようなもの。多くのREST APIでは、この目的で「トークン」と呼ばれる文字列を毎回いっしょに送ります。仕組みの詳しい話はトークン認証とはで解説しています。
返ってくるもの：JSONとステータスコード
リクエストを送ると、サーバから返事が返ってきます。REST APIでは、このデータの中身に「JSON」という形式がよく使われます。JSONは、人間にもコンピュータにも読みやすい、データの書き方のルールだと思ってください。名前と値がセットで並んだ、整理された箇条書きのようなものです。
そしてもうひとつ、返事には「ステータスコード」という3桁の番号がつきます。これは結果を短く伝える合図で、代表的なものは次のとおりです。
- 200 … うまくいった(成功)
- 404 … 探したものが見つからなかった
- 500 … サーバの側で何か問題が起きた
番号を見るだけで、うまくいったのか、どこでつまずいたのかの見当がつきます。天気予報のマークのように、細かい説明を読まなくても状況がひと目で分かる仕組みです。
RESTでない世界と比べてみる
なぜ、わざわざこうした作法が広まったのでしょうか。それは、昔はAPIの作り方が作る人ごとにバラバラだったからです。あるサービスでは削除が deleteUser という命令名で、別のサービスでは remove だったりと、つなぐたびに相手ごとのクセを覚え直す必要がありました。
RESTという共通の作法が広まったことで、「モノはURLで、操作はメソッドで」という同じ形が多くのサービスで通じるようになりました。一度作法を覚えれば、初めて触るAPIでも見当がつきやすい。この分かりやすさが、RESTが今の主流になっている理由です。ほかにGraphQLといった別の考え方の仕組みもありますが、まず基本として押さえたいのはRESTだと考えて差し支えありません。
つまずきポイント：URLは名詞、操作はメソッド
初心者がつまずきやすいのが、URLに「動詞」を入れてしまうことです。たとえば /getUsers や /deleteUser/123 のように、URLの中に「取得する」「削除する」といった動作を書きたくなります。
でもRESTの作法では、URLはあくまで名詞(モノの名前)にとどめ、動作はHTTPメソッドで表すのが基本です。「取得」ならGETで /users、「削除」ならDELETEで /users/123。この「住所は名詞、頼み方は動詞」という役割分担を混同すると、RESTらしくない形になってしまいます。ここは最初に意識しておくと、後の理解がぐっと楽になります。
getUsers って書きたくなるなあ。動詞はメソッドにまかせるのがルールなんだね。
次の一歩
REST APIは、Webの標準的な仕組みの上に「モノの数え方」と「操作の言い方」の作法を重ねたもの、と押さえておけば十分です。
理解を広げるなら、まず土台としてAPIとはでAPIそのものの役割を確認し、ステートレスにつながる本人確認のしくみとしてトークン認証とはを、そしてREST APIを実際に呼ぶときに出会いやすい壁としてCORSエラーとはを読んでおくと、点と点がつながっていきます。
まとめ
- REST APIは「Webの標準ルール(HTTP)に沿って、データをリソースとしてやり取りするAPIの作法」。
- URLは「モノ(リソース)」を表す名詞。
/users/123は「ID123のユーザー」を指す。 - 操作はHTTPメソッドで表す。GET=取得 / POST=作成 / PUT・PATCH=更新 / DELETE=削除。
- サーバは前のやり取りを覚えない(ステートレス)ので、毎回必要な情報を送る。だから認証にトークンなどが要る。
- 返事はJSONで届き、200・404・500などのステータスコードで結果が分かる。
独学でつまずきやすいのは、こうした一つひとつの知識そのものよりも「何をどの順番で学ぶか」です。REST APIやWebの仕組みも、あなたの目標から逆算した学ぶ順番の中に置いてはじめて、迷わず前に進めます。
