絵で見てわかるWeb APIの仕組み｜書籍の要点を漫画で紹介

書籍紹介漫画を読む(カラー版・全32ページ)

まんがは右上のコマから左へ読みます。左右の矢印ボタンでページを送れます。画像をクリックすると大きく表示できます。まんがは右上のコマから左へ読みます。横にスワイプ、または左右の矢印ボタンでページを送れます。画像をタップすると大きく表示できます。

Web APIの基本：3つの要素とスタイル（第1〜3章）

漫画の前半では、武田さんがWeb APIの土台を案内します。たぬきの「APIとWeb APIの違いは何ですか？」という問いから始まります。

APIは3つの要素でできている

図1　APIの3つの要素と、Web APIでの対応（漫画6ページより）

APIは、3つの要素でできています。Web APIでは、それぞれが次のものにあたります。

どれも、ふだん使っているものです。たぬきのアプリの通信にも、この3つがちゃんと出ています。

URL・HTTP・データ形式の見方

図2　URLとHTTPの見方（漫画7・8ページより）

URLを見ると、どこの何を呼んでいるかが分かります。HTTPは、頼み方と答え方の決まりです。データの形は、目的に合わせていくつかあります。

• URL：どのサーバーか（api.example）と、どのデータか（/articles）
• HTTP：頼む側のGET（データを取ってくる）と、答える側の200 OK（うまくいった）・content-type（中身の形式）
• データ形式：JSON・XML・バイナリ形式

この3つが、Web APIの土台です。

SOAP・REST・gRPC・GraphQLは立ち位置が違う

図3　4つの技術の位置づけと、SOAPとRESTの違い（漫画10ページより）

土台の上で、APIをどう作るかの考え方を「スタイル」と呼びます。ただし、SOAP・REST・gRPC・GraphQLの4つは、同じ種類のものではありません。

RESTは考え方の名前で、REST APIはHTTPを活かして作ります。何をするかはHTTPメソッドで、成否はステータスコードで伝えます。SOAPは、どちらも主にXMLの中に書きます。

PR

絵で見てわかるWeb APIの仕組み

著：武田 大輝・枇榔 晃裕・渋川 よしき・真野 隼記／翔泳社／2026年9月16日発売／304ページ

漫画で紹介したAPIの3つの要素や、SOAP・REST・gRPC・GraphQLの違いは、書籍の第1〜3章でくわしく解説しています。

書籍の詳細を見る（Amazon）

性能・認証と認可・セキュリティ・テスト（第4〜7章）

ここからは、枇榔さんが案内します。作る側の話が多くなりそうですが、使う側にも関わる話です。

速さは使う側でも変わる（性能と最適化）

図4　キャッシュとやり直しの決まり（漫画13ページより）

表示が遅いのは、サーバーのせいだけとは限りません。使う側でも速さは変わります。たとえば、結果を使い回す「キャッシュ」があります。

• キャッシュ：ためるのは、データを読むだけの通信が基本。書き換える通信の結果をためると、古い結果が返って最新の状態が伝わらない
• 一時的な失敗（通信の不調、サーバーの一時的な停止、時間切れ）：回数を決めてやり直す
• やり直しても直らない失敗（URLや送る値の間違い、認証情報の期限切れ）：やり直さずエラーを表示する

認証と認可、確かめる3つの場所

図5　認証と認可、確かめる3つの場所（漫画14・15ページより）

誰なのかを確かめるのが「認証」、何をしてよいかを決めるのが「認可」です。認可で確かめる場所は、入口・データ・出口の3つです。

• 入口：この機能を使ってよいか
• データ：このデータを扱ってよいか（下書きは持ち主にだけ見せる）
• 出口：見る人に合わせて、返す項目を選ぶ

セキュリティで守る3つの場所

図6　セキュリティで守る3つの場所（漫画16ページより）

守ることは、認可だけではありません。悪意のある人から、システムとデータを守るのがセキュリティです。守る場所は3つあり、使う側のブラウザも含まれます。

• ブラウザ：アプリが動く所
• 通信経路：アプリとサーバーの間
• サーバー：データがある所

決めつける前に、実際の通信を見る（テストとデバッグ）

図7　通信を見て原因を見つける（漫画18ページより）

記事一覧がエラーのままのとき、原因を決めつける前に、実際の通信を見ます。漫画では、記事一覧の通信だけが404でした。

1. 404は「見つからない」という意味
2. 送ったURLを正しいURLと比べると、articlesの「s」が抜けていた
3. 直した後は、テストで動き続けるかを確かめる

PR

絵で見てわかるWeb APIの仕組み

著：武田 大輝・枇榔 晃裕・渋川 よしき・真野 隼記／翔泳社／2026年9月16日発売／304ページ

キャッシュとやり直しの決まり、認証と認可、セキュリティ、テストとデバッグは、書籍の第4〜7章でくわしく解説しています。

書籍の詳細を見る（Amazon）

画面との連携・通信の形・開発のコミュニケーション（第8〜10章）

後半は、渋川さんと真野さんが、アプリの画面とWeb APIのつながりや、開発の現場での進め方を案内します。

通信の2つの形と、間に入るService Worker

図8　通信の2つの形と、Service Worker（漫画20・21ページより）

画面とAPIの通信には、1回ずつ頼む形と、つないだままの形があります。さらに、画面とサーバーの間に入る仕組みとして、Service Workerがあります。

• 単発の通信：1回ずつ頼んで答える
• つないだままの通信：つないだまま、続けてやりとりする
• Service Worker：ためたデータ（キャッシュ）を返せるので、つながらない時も表示できる

実際のサービスで使われる4つの通信の形

図9　実際のサービスで使われる4つの通信の形（漫画22・23ページより）

実際のサービスでは、いろいろな通信の形が使われています。どれを使うかは、目的から考えます。

頼むときは、理由も一緒に伝える

図10　変える前に調べることと、頼むときに伝えること（漫画25ページより）

画面では簡単に見える変更でも、APIの裏側では確認することが多くあります。だからこそ、APIの担当者に頼むときは、理由も一緒に伝えます。

• 変える前に調べること：誰に見せてよいか（認可）、今の設計と合うか、変えたときの影響（影響度調査）
• 頼むときに伝えること：何をしてほしいか（What）と、なぜ必要か（Why）
• 理由が分かると、優先度や期日を相談しやすくなる

PR

絵で見てわかるWeb APIの仕組み

著：武田 大輝・枇榔 晃裕・渋川 よしき・真野 隼記／翔泳社／2026年9月16日発売／304ページ

画面とAPIの通信の形やService Worker、APIの担当者への頼み方は、書籍の第8〜10章でくわしく解説しています。

書籍の詳細を見る（Amazon）

変わるものと、変わらない土台（第11章）

図11　入れ替わっていく選択肢と、使い続ける土台（漫画27ページより）

Web APIの技術は、これからも変わります。それでも、変わらない土台があります。今までの話の中にも、変わるものと変わらないものの両方が出てきました。

土台が分かっていれば、新しい技術が出ても慌てずに済みます。漫画では、新しいフロントエンドフレームワークのニュースを見たたぬきが、画面を作る道具は変わっても、クライアントとサーバーの関係は土台だと気づきます。

絵で見てわかるWeb APIの仕組みのまとめ

最後に、漫画の要点を振り返ります。

Web APIの仕組みをもっと詳しく知りたい方は、次の記事をご覧ください。

Web APIの仕組みを詳しく読む

PR

絵で見てわかるWeb APIの仕組み

著：武田 大輝・枇榔 晃裕・渋川 よしき・真野 隼記／翔泳社／2026年9月16日発売／304ページ

漫画で紹介した、Web APIの土台から品質・現場での使い方・これからの変化までを、くわしく学べる一冊です。

書籍の詳細を見る（Amazon）