クライアント アプリケーション（モバイルアプリ、ウェブブラウザ、別のサーバーなど）が、アクションを実行するために API へのリクエストを開始します。このリクエストは特定の URL に送信され、HTTP メソッド、メタデータを含むヘッダー、場合によってはデータを含むリクエストの本文が含まれます。

サーバーはリクエストを受信して検証し、クライアントが認証され、リクエストされたアクションを実行する権限があることを確認します。その後、リクエストを処理します。これには、データベースからのデータの取得、新しいリソースの作成、既存のリソースの更新などが含まれます。

リクエストを処理した後、サーバーはレスポンスをクライアントに返します。このレスポンスには、結果を示す HTTP ステータス コード（成功の場合は 200 OK、リソースが存在しない場合は 404 Not Found、セキュリティ上の問題がある場合は 401 Unauthorized など）と、リクエストされたデータがレスポンスの本文に含まれます。

クライアントとサーバー間で転送されるデータは、リソースの状態の「表現」です。JSON（JavaScript Object Notation）は、軽量で人間が読める形式であり、プログラミング言語で簡単に解析できるため、このデータの最も一般的な形式となっています。

REST の能力とスケーラビリティは、その設計を導く一連のアーキテクチャ上の制約から生まれます。これらの制約に従うシステムは「RESTful」とみなされます。

リソースは REST の基本的な概念です。リソースは、型、関連データ、他のリソースとの関係、およびリソースに対して動作する一連のメソッドを持つオブジェクトです。たとえば、e コマース API では、「商品」や「顧客」がリソースになります。

各リソースは URI によって一意に識別されます。適切に設計された API は、リソースを識別するために、明確で説明的かつ一貫性のある URI を使用します。たとえば、/users はユーザーのコレクションを識別し、/users/123 は ID が 123 の特定のユーザーを識別します。

クライアントはリソースと直接やり取りするのではなく、そのリソースの表現とやり取りします。最も一般的な表現形式は JSON ですが、XML や HTML などの形式も使用できます。これにより、リソースの状態を柔軟に表現できます。

クライアントからサーバーへのリクエストには、サーバーがリクエストを理解して処理するために必要なすべての情報が含まれている必要があります。サーバーは、リクエスト間でクライアント コンテキストやセッション状態を保存しません。この制約により、どのサーバーでもリクエストを処理できるため、REST API は非常にスケーラブルになります。

クライアントとサーバーは分離されており、API が両者のインターフェースとして機能します。このように関心を分離することで、クライアントサイド アプリケーションとサーバーサイド アプリケーションを個別に進化させることができます。

REST では、クライアントとサーバー間で一貫した統一インターフェースが必要です。これは、標準の HTTP メソッド、リソース識別用の URI、アプリケーション状態のエンジンとしてのハイパーメディア（HATEOAS）を使用することで実現されます。

サーバーからのレスポンスは、キャッシュ可能またはキャッシュ不可として定義する必要があります。レスポンスがキャッシュ可能である場合、クライアントまたは仲介者は、後続の同一のリクエストに対してそのレスポンスを再利用できます。これにより、パフォーマンスが大幅に向上し、サーバーの負荷が軽減されます。

REST API に接続されたクライアントは通常、エンドサーバーに直接接続されているか、途中の仲介者に接続されているかを判別できません。API ゲートウェイやロードバランサなどの仲介サーバーをアーキテクチャに導入して、スケーラビリティ、セキュリティ、パフォーマンスを向上させることができます。

一般的なユースケースとして、モバイル天気アプリが特定の場所の現在の天気を公開天気 API から取得する場合があります。

クライアント アプリケーションは、API エンドポイントに HTTP GET リクエストを送信します。このリクエストには、場所と認証用の API キーが含まれます。

サーバーはリクエストを処理し、指定された場所の天気データを取得して、JSON レスポンスを返します。

マイクロサービス アーキテクチャでは、「商品」サービスが「在庫」サービスから最新の価格を取得してから、e コマースサイトに表示する必要がある場合があります。

商品サービスは、特定の商品 ID について、在庫サービスの API エンドポイントに内部 HTTP GET リクエストを行います。

在庫サービスは現在の価格を検索し、単純な JSON レスポンスを返します。