バックエンドの仕事が減った経緯
フロントエンドが画面のどこに何があるかを決めるなら、バックエンドはそこに何を表示するかを決める。どちらも結局はサーバーで要求を受けて値を返す仕事だ。
この区分は昔からこうだったわけではない。バックエンドの道具が画面まで一緒に描いていたからだ。データの形を決める部分、画面を描く部分、その間をつなぐ部分を一つの枠に置く方式で、この構成を MVC パターンと呼んだ。Python では Django が長くその席にいた。
そして前回見たとおり画面を描く仕事が Next.js 側へ移った。すると三つの部分のうち画面を描いていた部分が抜け、残ったのは何の値を返すかという一つになった。
その仕事だけをする軽い道具が席に着いた。それが FastAPI である。バイブコーディングでこの名前が頻繁に出るのは、いまその席がここにあるからだ。言語ごとにこうした道具は複数あり、Java の Spring、PHP の Laravel が同じ位置にある。
API と JSON
API はプログラム同士がつながる窓口だ。人とコンピュータが出会う場所をユーザーインターフェースと呼ぶように、プログラムとプログラムが出会う場所もそう呼ぶ。
フロントエンドとバックエンドも結局この窓口で会話する。フロントエンドが画面に描く枠を用意し、バックエンドにここへ入れる値をくれと要求すると、バックエンドが答えを返す。
その答えの形式が JSON である。波括弧を開き、名前と値を組にしてカンマでつなぐ形だ。決まった形式があってこそ、受け取る側が機械的に解釈できる。
バックエンドもフロントエンドと構造は同じだ。他人が作ったライブラリを pip で受け取り自分のコードと合わせる。npm と同じ位置で、名前が違うだけである。
要求 GET /api/posts?page=2
応答 {
"items": [
{ "id": 11, "title": "最初の記事" },
{ "id": 12, "title": "二つ目の記事" }
],
"total": 57,
"page": 2,
"pageSize": 10
}API 設計は三つを決めること
API にも設計という言葉が付く。決めるべきものが三つあるからだ。
一つ目は住所の規則である。どの住所で呼べば一覧で、どの住所なら一件の詳細かを決める。規則があってこそ、次の人が住所を見ただけで何をするか分かる。
二つ目は動作の区別だ。利用者がすることは結局、作る・読む・直す・消すの四つに整理される。頭文字を取って CRUD と呼ぶ。同じ住所でもどの方式で要求したかでこの四つを分ける。
三つ目は応答の形である。これが最も抜けやすい。一覧を返すなら項目だけでは足りない。全部で何件か、いまが何ページ目かが一緒にあってこそ画面でページ送りを描ける。ログインの応答もエラーの応答もそれぞれ形を決めておく。
| 動作 | 要求方式 | 住所の例 |
|---|---|---|
| 一覧を読む | GET | /api/posts |
| 一件を読む | GET | /api/posts/12 |
| 作る | POST | /api/posts |
| 直す | PUT · PATCH | /api/posts/12 |
| 消す | DELETE | /api/posts/12 |
エージェントに任せるときは先にこの三つを渡す
この三つを決めるのは、もともと他の開発者と協働するためだった。規則があってこそ、他人の作った API を当て推量で使わずに済む。
エージェントに任せるときも同じ理由で価値がある。決めておかないと毎回違う形が出てくる。昨日の一覧には total があったのに今日作ったものにはなく、エラーの形式が画面ごとに違う。すると画面側のコードが揺れ続ける。
だから順番を変える。コードを作ってくれと言う前に、住所の規則・動作の区別・応答の形の三つを文書として決めて渡す。そのうえでこの規格どおりに作ってくれと言う。
この三つを前に置くだけで、後ろに付くコードははるかに揺れなくなる。次回はこのバックエンドが値を取り出す場所、データベースを見る。