エンドポイントの基本
エンドポイントの作成
APIs モジュール内で新しいエンドポイントを作成するには、New Endpoint ボタンをクリックします。1.
2.
3.
4.
5.
Design-first Mode
Request-first Mode
インターフェースモード
エンドポイントパス
/users）のみを入力すれば十分です。ベース URL は環境で設定され、Apidog はエンドポイントへリクエストを送信する際に自動的にそれを追加します。/ で始めることも推奨しています。これにより API 設計が明確かつ整理された状態になり、Apidog の機能を最大限に活用できます。パスを / で始め る理由
/ で始めることは、OAS に準拠するために推奨されます。パスを / で始めない場合、OpenAPI エコシステム内のツールを使用する際に、さまざまな互換性の問題が発生する可能性があります。/ を使用すると、Apidog でのテストおよび検証に不可欠な URL パターンモック機能を利用できます。リクエストメソッド
| メソッド | 説明 |
|---|---|
| GET | 副作用なしに指定されたリソースを取得します。データの送信にはクエリパラメータを使用します。 |
| POST | 処理のためにデータを送信し、副作用を伴う場合があります。データは通常、リクエストボディで送信されます。 |
| PUT | 指定されたリソースを完全に更新または置換します 。 |
| DELETE | 指定されたリソースを削除します。 |
| OPTIONS | 対象リソースでサポートされている HTTP メソッドについて問い合わせます。 |
| HEAD | GET と似ていますが、レスポンスヘッダーのみを取得します。リソースの内容をダウンロードせずに、リソースの存在や変更を確認する場合に便利です。 |
| PATCH | 指定されたリソースの一部情報を更新します。 |
| TRACE | サーバーが受信したリクエストを返します。主にデバッグおよび診断目的で使用されます。 |
| CONNECT | サーバーへのトンネルを確立します。通常、プロキシサーバーによるリクエスト転送に使用されます。 |
エンドポイントメタデータ
| フィールド | 説明 |
|---|---|
| Name | エンドポイントの機能を示す説明的な名前です。 |
| Status | デフォルトのステータスは「Developing」です。Testing や Production など、異なる段階を反映するように変更できます。Endpoint status の詳細をご確認ください。 |
| Maintainer | エンドポイントを担当する Apidog チームメンバーを指定します。アカウント内のユーザーを選択して、このロールを割り当てます。 |
| Tags | エンドポイントを分類または説明するキーワードやフレーズです。新しいタグを作成することも、既存のタグから選択することもできます。 |
| Service | エンドポイントパスが追加されるベース URL です。デフォルトでは「Inherit from parents」に設定されていますが、環境設定を通じて手動で指定できます。Environments and services の詳細をご確認ください。 |
| OperationId | API 内でこの操作を区別する一意の識別子（OAS における operationId）です。 |
| Description | エンドポイントの目的と使用方法に関する詳細情報です。より高度な書式設定のために Markdown をサポートしています。 |
カスタムフィールド
リクエスト
リクエストパラメータ
クエリパラメータ
? の後に URL の末尾へ追加され、& で区切られるキーと値のペアです。例：?id=2&status=available。API エンドポイントの出力をフィルタリング、並べ替え、または変更するために使用されます。INFO
パスパラメータ
/pets/{id}、誤った例：/pets/:id。{parameter} として定義し、その後パラメー タ値に {{variable}} を使用することです。例：推奨：変数をパスパラメータ値に配置します
非推奨：変数を URL に直接配置します
{parameter} と {{variable}} を混同しないでください
{parameter}：単一の波括弧は、Apidog におけるパスパラメータを表します。パスパラメータは URL パス内のプレースホルダーであり、API エンドポイントにアクセスされた際に特定の値へ動的に変更されます。{{variable}}：二重の波括弧は、リクエスト内の変数を含めるために使用されます。これらの変数はリクエスト送信時に実際の値へ置換でき、API とのやり取りにおいて動的でカスタマイズ可能な入力を可能にします。パスで {{variable}} を使用してはいけない理由
{{variable}} を使用すると OAS に準拠しません。OAS に従うことで、OpenAPI エコシステム内のさまざまなツールとシームレスに統合できます。{{variable}} を使用すると、Apidog の URL パターンモック機能を使用できなくなります。ヘッダーパラメータ
詳細
ボディパラメータ
詳細
パラメータの説明
| プロパティ | 説明 |
|---|---|
| Name | 説明対象のパラメータ名を指定します。これは必須フィールドであり、定義するパラメータを正確に表す必要があります。 |
| Type | パラメータ値のデータ型を指定します。一般的な値には string、number、integer、boolean、array、object などがあります。このプロパティは、パラメータ値の形式と構造を定義するのに役立ちます。 |
| Description | パラメータに関する簡潔な説明またはドキュメントを提供します。ユーザーがパラメータの目的と使用方法を理解するのに役立ちます。 |
| Required | API リクエストにおいてパラメータが必須かどうかを指定します。これはブール値（true または false）であり、パラメータをリクエストに含める必要があるかどうかを示します。 |
| Advanced Settings | パラメータのデータ型、形式、制約を定義します。パラメータ値の期待される構造と内容に関する詳細情報を提供できます。 |
Type Editor
スキーマ
JSON または XML の場合、データ構造を設定する必要があります。データ構造はスキーマを参照できます。詳細
レスポンスと例
| コンポーネント | 説明 |
|---|---|
| HTTP Status Code | エンドポイントが返す可能性のあるすべてのレスポンスステータスを決定します。これには 200（OK）、404（Not Found）、500（Server Error）などの標準レスポンスが含まれます。 |
| Data Format | 各ス テータスコードに対して API が返すレスポンスの形式を定義します。これは JSON、XML、HTML、Raw、Binary、またはその他の適切な形式にできます。 |
| Schema | データを含むレスポンス（主に 200 ステータス）の場合、レスポンスペイロードの構造を詳述します。これには、型、ネストされたオブジェクト、任意フィールド、配列の指定が含まれます。明確な定義により、クライアント開発者は期待されるデータとその解析方法を理解できます。スキーマを設定できるのは JSON と XML のみです。詳細情報については、Schemas を参照してください。 |
| Example | 例のレスポンスを提供することは、実際のシナリオで API がどのように動作するかを示すために不可欠です。例は、事前定義されたリクエストでエンドポイントが呼び出された際にサーバーから返されるサンプルデータセットである ことが理想的です。レスポンスのスキーマで定義された構造、データ形式、型を反映している必要があります。 |
レスポンスの追加
200 OK レスポンスは、出力データの要件が異なるためエンドポイントごとに異なることが多い一方で、400 Bad Request や 404 Not Found などのエラーレスポンスは、異なるエンドポイント間で一貫している傾向があります。Apidog はこの共通性に対して Response Component 機能でスマートに対応しており、事前定義されたエラーレスポンスの再利用を可能にします。これにより、API ドキュメント作成プロセスがより効率的になり、API の動作もより一貫したものになります。Response Components
レスポンス例の追加
例の自動生成
エンドポイントのプレビュー
Modified at 2026-06-11 07:06:02