トークン化とは、機密データを「トークン」と呼ばれる非機密のプレースホルダーと交換するプロセスです。これらのトークンは元のデータの形式や長さを保持しますが、それ自体には悪用可能な価値はありません。APIセキュリティの文脈において、トークン化は強力な防御メカニズムとして機能します。ユーザーがアプリケーションプログラミングインターフェースを通じて支払い詳細、医療記録、または個人情報を送信する際、システムは実際の保存やさらなる処理が行われる前に、この重要なデータをデジタル・トークンとシームレスに置き換えます。 トークン化は、デジタル環境を保護するために具体的にどのように機能するのでしょうか？標準的なワークフローは、一般的に4つの主要な、厳密に管理されたステップを含みます。 * データキャプチャ：機密情報が、ユーザーまたはアプリケーションからのセキュアなAPIリクエストを通じてシステムに入力されます。 * トークン生成：セキュアなトークンジェネレータが、実際の機密データの代替として、ランダムな文字列（トークン）を作成します。この生成されたトークンは、元の入力とは一切関係がありません。

Oliver Kingsley

3月 13, 2026

TL;DR 現代のブラウザでシンプルなリアルタイム通信を行うには、ネイティブWebSocketを使用します。自動再接続、フォールバックトランスポート、またはルーム/ネームスペースが必要な場合は、Socket.IOを使用します。Socket.IOは200KB以上のオーバーヘッドを追加しますが、エッジケースに対応します。Modern PetstoreAPIは両方を実装しています。オークションにはネイティブWebSocket、チャットにはSocket.IOを使用しています。 はじめに リアルタイムの双方向通信が必要な場合、ネイティブWebSocketとSocket.IOのどちらを使用すべきでしょうか？ネイティブWebSocketはブラウザに組み込まれており、高速です。Socket.IOは機能を追加しますが、バンドルサイズが200KB以上増加します。 Modern PetstoreAPIは両方を使用しています。ライブペットオークションなどパフォーマンスが重要な場面ではネイティブWebSocketを、自動再接続やルームが価値を発揮するカスタマーサポートチャットではSocket.IOを使

Ashley Innocent

3月 13, 2026

要約 バッテリーが制限されている、ネットワークが不安定な、またはパブリッシュ/サブスクライブ（pub-sub）メッセージングパターンを使用するIoTデバイスにはMQTTを使用してください。標準的なウェブ/モバイルAPIにはHTTPを使用してください。MQTTは2バイトのヘッダーを使用するのに対し、HTTPは100バイト以上を使用するため、制約のあるデバイスに最適です。Modern PetstoreAPIは、ペット追跡用首輪やスマート給餌器にMQTTを実装しています。 はじめに あなたのペット追跡用首輪は、5分ごとに位置情報を送信する必要があります。この首輪は、6ヶ月持続するはずのコイン型電池で動作します。HTTPを使用すると、バッテリーは2週間で切れてしまいますが、MQTTを使用すると、丸6ヶ月持ちます。 HTTPはAPIの標準ですが、IoTデバイスではなくウェブブラウザ向けに設計されています。MQTT (Message Queuing Telemetry Transport) は、帯域幅が制限され、ネットワークが不安定な制約のあるデバイス向けに作られました。 Modern

Ashley Innocent

3月 13, 2026

要約 (TL;DR) 通知やライブフィードのような一方向のサーバーからクライアントへの更新には、Server-Sent Events (SSE) を使用します。チャットやゲームのような双方向通信には WebSocket を使用します。SSE はよりシンプルで HTTP 上で動作します。WebSocket はより複雑ですが、双方向メッセージングをサポートします。Modern PetstoreAPI は、異なるリアルタイムのユースケースのために両方を実装しています。 はじめに API でリアルタイムの更新が必要だとします。ペットのステータスが「利用可能」から「引き取られました」に変わったとき、クライアントはすぐに知る必要があります。このとき、WebSocket と Server-Sent Events (SSE) のどちらを使うべきでしょうか？ ほとんどの開発者は「より強力な」WebSocket をデフォルトで選びがちです。しかし、SSE の方が多くの場合、より良い選択肢です。SSE はよりシンプルで、標準の HTTP 上で動作し、自動再接続を処理します。WebSocket は、

Ashley Innocent

3月 13, 2026

要約 Model Context Protocol (MCP) は、AIアシスタントを外部データソースやAPIに接続するための標準規格です。これにより、Claude Desktop、Cursor、その他のAIツールがAPIに安全にアクセスできるようになります。Modern PetstoreAPIはMCPを実装しており、AIアシスタントが自然言語を介してペットの検索、注文、在庫管理を行うことができます。 はじめに Claude Desktopに「300ドル以下の利用可能な猫を見せてください」と尋ねると、Claudeは「ペットストアのデータにアクセスできません」と答えます。ワークフローを中断して、APIからコピー＆ペーストする必要があるでしょう。 MCP（Model Context Protocol）を使用すると、ClaudeはあなたのAPIに直接アクセスできます。同じ質問をすると、ClaudeはPetstoreAPIを照会し、結果をフィルタリングして、300ドル以下の利用可能な猫を表示します。 Modern PetstoreAPIはMCPを実装しており、AIアシスタントが自然

Ashley Innocent

3月 13, 2026

要約 (TL;DR) イベント駆動型APIは、外部通知にウェブフックを、内部処理にメッセージキューを使用します。イベントをキュー（RabbitMQ、Kafkaなど）に発行し、非同期で処理し、ウェブフックを通じてクライアントに通知します。モダンなPetstoreAPIは、注文処理、在庫更新、支払い通知にこのパターンを使用しています。 はじめに 顧客が注文を行います。あなたのAPIは、支払い処理、在庫更新、メール送信、倉庫への通知、ウェブフックのトリガーを行う必要があります。これらすべてを同期的に行い、顧客を10秒間待たせますか？それとも、すぐに応答し、非同期で処理しますか？ イベント駆動型APIは、迅速に応答し、バックグラウンドで処理を行います。注文のエンドポイントはすぐに201 Createdを返します。イベントがバックグラウンド処理をトリガーします。完了すると、ウェブフックがクライアントに通知します。 モダンPetstoreAPIは、注文、支払い、在庫にイベント駆動型アーキテクチャを使用しています。 Apidogは、ウェブフックのテスト、イベントフローの検証、非同期処理

Ashley Innocent

3月 13, 2026

要約 SSE（Server-Sent Events）を使用してHTTP経由でAPIレスポンスをストリーミングします。`Content-Type: text/event-stream` を送信し、イベントを `data: {json}\n\n` の形式で記述します。SSEは、AIレスポンスのストリーミング、進捗状況の更新、ライブフィードに機能します。Modern PetstoreAPIは、AIペット推薦と注文ステータスの更新にSSEを使用しています。 はじめに あなたのAPIはペットのAI推薦を生成します。その応答には10秒かかります。ユーザーを待たせますか、それとも生成された結果をストリーミングしますか？ Server-Sent Events（SSE）を使用すると、リアルタイムでレスポンスをストリーミングできます。AIが結果を生成するにつれて、ユーザーはすぐにそれらを見ることができ、より良い体験を生み出します。 Modern PetstoreAPIは、AIペット推薦、注文ステータスの更新、在庫変更にSSEを使用しています。 ストリーミングAPIをテストする場合、Apido

Ashley Innocent

3月 13, 2026

要約 信頼性の高いWebhookを設計するには、指数関数的バックオフによるリトライ（5～10回）、べき等性キー、HMAC署名検証、5秒のタイムアウトを実装しましょう。2xx応答はすぐに返し、処理は非同期で行います。Modern PetstoreAPIは、注文更新、ペットの引き取り、支払い通知のためのWebhookを、完全なリトライとセキュリティ機能とともに実装しています。 はじめに クライアントにペットが引き取られたことを通知するためにWebhookを送信しました。しかし、クライアントのサーバーがダウンしています。Webhookは失敗します。リトライしますか？何回？もしクライアントがWebhookを2回受け取ってしまい、顧客に2回請求してしまったらどうなりますか？ Webhookは、イベントが発生した際にクライアントのURLにイベントをプッシュするHTTPコールバックです。理論的には単純ですが、実際には複雑です。ネットワークの障害、サーバーのクラッシュ、クライアント側のバグなどが起こり得ます。本番環境のWebhookには、リトライロジック、べき等性、セキュリティ、監視が必要で

Ashley Innocent

3月 13, 2026

TL;DR（要点） OAuth 2.0スコープは、アクセストークンが実行できる操作を定義する権限文字列です。`pets:read`や`orders:write`のように`リソース:アクション`形式を使用します。認証時にスコープを要求し、APIエンドポイントでそれらを検証します。Modern PetstoreAPIは、ペット、注文、ユーザーデータへの読み取り/書き込みアクセスにスコープを実装しています。 はじめに サードパーティ製アプリがペットストアの在庫を読み取りたいと考えています。そのアプリは、注文の作成、ペットの削除、ユーザーの管理に対してフルアクセスを持つべきでしょうか？いいえ、在庫の読み取りのみを行うべきです。 OAuth 2.0スコープがこれを解決します。スコープはアクセストークンが持つ権限を定義します。アプリは`inventory:read`スコープを要求します。あなたのAPIは、データを返す前にトークンがこのスコープを持っていることを検証します。 Modern PetstoreAPIは、ペット、注文、在庫、ユーザーといったすべてのリソースに対して、きめ細かいス

Ashley Innocent

3月 13, 2026

要点（TL;DR） パブリックAPIやシンプルなCRUD操作にはRESTを使用します。クライアントが柔軟なデータ取得を必要とし、オーバーフェッチを減らしたい場合はGraphQLを使用します。高性能なマイクロサービス間通信にはgRPCを使用します。Modern PetstoreAPIはこれら3つのプロトコルすべてを実装しており、各ユースケースに最適なツールを選択できます。 はじめに あなたはAPIを構築しています。REST、GraphQL、それともgRPCを使うべきでしょうか？それぞれのプロトコルには、自分のものが最高だと主張する熱心な支持者がいます。しかし実のところ、これらはすべて異なる得意分野を持っています。 RESTは普遍的でシンプルです。GraphQLはクライアントにデータ取得の制御を与えます。gRPCは高速で、内部サービスにとって効率的です。最適な選択は、どのプロトコルが「優れているか」ではなく、あなたのユースケースによって決まります。 ほとんどのAPIは1つのプロトコルを選び、それを使い続けます。Modern PetstoreAPIは異なるアプローチを取っています

Ashley Innocent

3月 13, 2026

要約 OpenAPI 3.1では、JSONスキーマとの完全な互換性、Webhook、およびディスグリミネーターの改善が追加されました。OpenAPI 3.2では、QUERYメソッドのサポート、例の改善、およびセキュリティ定義の強化が追加されました。Modern PetstoreAPIは、OpenAPI 3.2を使用して、すべての最新機能を本番環境で利用可能な例とともに示しています。 はじめに OpenAPI仕様を作成していると、OpenAPI 3.0、3.1、3.2への言及を目にすることがあります。それらの違いは何でしょうか？アップグレードすべきでしょうか？お使いのツールは新しいバージョンをサポートするでしょうか？ OpenAPIは3.0から3.2へと大幅に進化しました。各バージョンでは、API仕様をより強力かつ正確にする機能が追加されています。しかし、すべてのツールが最新バージョンをサポートしているわけではないため、互換性の課題が生じています。 古いSwagger PetstoreはOpenAPI 2.0（Swagger仕様）を使用しています。Modern Petstor

Ashley Innocent

3月 13, 2026

TL;DR (要約) プロトコル層からビジネスロジックを分離することで、マルチプロトコルAPIを構築します。共通のドメイン層を作成し、その上にREST、GraphQL、gRPCアダプターを追加します。モダンPetstoreAPIは、これら3つのプロトコルすべてで一貫したデータモデルを持つこのアーキテクチャを示しています。 はじめに あなたのAPIは、ウェブクライアント、モバイルアプリ、内部マイクロサービスにサービスを提供しています。ウェブクライアントはシンプルさのためにRESTを、モバイルアプリはデータ転送を減らすためにGraphQLを、マイクロサービスはパフォーマンスのためにgRPCを求めています。これら3つのために、それぞれ別々のAPIを構築しますか？ いいえ。3つのプロトコル層を持つ1つのAPIを構築します。ビジネスロジックは同じままで、プロトコルアダプターだけが変更されます。これがマルチプロトコルAPIアーキテクチャです。 モダンPetstoreAPIは、共有されたコアからREST、GraphQL、gRPCを実装しています。同じペットストアロジックが、一貫した動作で

Ashley Innocent

3月 13, 2026

REST APIはHATEOASハイパーメディアリンクを実装すべきか？ TL;DR（要するに） HATEOAS（Hypermedia as the Engine of Application State）は理論的には優雅ですが、実用上は複雑です。ほとんどのAPIは完全なHATEOASをスキップし、ページネーション、関連リソース、アクションのために選択的にハイパーメディアリンクを使用しています。Modern PetstoreAPIは、クライアントに完全にハイパーメディア駆動であることを強制することなく、実用的なハイパーメディアリンクを実装しています。 はじめに あなたはREST APIの設計について読んでいます。そこでHATEOAS（Hypermedia as the Engine of Application State）に出くわしました。説明にはこうあります：「クライアントはURLをハードコードするのではなく、ハイパーメディアリンクを通じて全てのアクションを発見すべきです。」 あなたはこう考えます：「それは複雑そうだ。実際にこんなことをしている人がいるのだろうか？」

Ashley Innocent

3月 13, 2026

要約 トークンバケットまたはスライディングウィンドウアルゴリズムを使用してAPIレート制限を実装します。制限を超過した場合は、標準のIETFレート制限ヘッダー（RateLimit-Limit、RateLimit-Remaining、RateLimit-Reset）と429 Too Many Requestsを返します。Modern PetstoreAPIは、ユーザーごとのクォータと明確なエラー応答でレート制限を実装しています。 はじめに クライアントが1分間に10,000件のリクエストをAPIに送信しました。データベースがクラッシュし、監視アラートが鳴り響き、他の顧客はAPIにアクセスできなくなりました。これは攻撃を受けているのかもしれませんし、単にリトライループに陥ったバグのあるクライアントを扱っているだけかもしれません。 レート制限はこれを防ぎます。クライアントが一定の時間枠内で行えるリクエストの数を制限します。制限を超過した場合、429 Too Many Requestsを返します。クライアントは処理を中断し、APIは健全な状態を保ちます。 古いSwagger Pet

Ashley Innocent

3月 13, 2026

要点 URLバージョニング（/v1/pets）は、ほとんどのチームにとって最も実用的なAPIバージョニング戦略です。視認性が高く、キャッシュ可能で、テストも簡単です。ヘッダーバージョニングとコンテンツネゴシエーションは、より「純粋な」RESTではありますが、複雑さを増します。Modern PetstoreAPIは、セマンティックバージョニングと明確な非推奨ポリシーを持つURLバージョニングを使用しています。 はじめに あなたのAPIに破壊的変更が必要です。/petsのレスポンス形式を、単なる配列からページネーションメタデータを含むラップされたオブジェクトに変更するからです。既存のクライアントは機能しなくなります。どうしますか？ APIバージョニングが必要です。しかし、どの戦略を選びますか？URLバージョニング（/v1/pets vs /v2/pets）？ヘッダーバージョニング（Accept: application/vnd.petstore.v1+json）？それともコンテンツネゴシエーション？それぞれの方法には熱心な支持者と強い意見があります。 結論から言うと、URLバー

Ashley Innocent

3月 13, 2026