Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

Apigee Edge を使用した開発

As a service provider, you develop APIs for consumption by client apps. You can use two different development methods to create, configure, and maintain API proxies and API products:

  • Edge サービスにアクセスするために Apigee RESTful API への HTTP リクエストを行います。
  • Edge 管理 UI ( を使用します。

いずれかの手法を使い始めるには、まず で無料のアカウントを作成する必要があります。詳細については、「Apigee Edge 開発環境の使用」を参照してください。

Client app developers access your services by making HTTP requests to your API proxies. There are no requirements on the type of client app, other than making a properly formatted HTTP request and handling data returned by the response.

If client app developers want to take advantage of the app-building features included with Edge API Services, their apps can make HTTP requests directly to those services.

管理 UI の使用

The Edge management UI is a browser-based tool you can use to create, configure, and manage API proxies and API products. There are a few tasks that require you to use the management API, though.

For an introductory tutorial using the management UI, see Create your first API proxy.

In the Edge management UI, you can:

  • Create API proxies by editing code and tracing flow of requests through your proxies.
  • Create API products that bundle proxies for exposure to client requests.
  • Manage developers and developer apps.
  • Configure your test and production environments.
  • Implement JavaScript and Node.js applications.

次の図に、API プロキシの作成および構成に使用できる Edge 管理 UI を示します。

RESTful 管理 API の使用

You can use Apigee Edge RESTful management APIs to create, configure, and manage API proxies and API products, policies for logic in your API proxies, apps and app developers, caches. The management API also provides access to low-level capabilities that are not exposed by the management UI for reasons of usability.

These API endpoints often take data containing configuration information and require you to pass authentication information, such as username and password, to access them. Following RESTful principles, you can call HTTP GET, POST, PUT, and DELETE methods on any of the API resources.

The following example uses cURL to execute an HTTP POST request to create an API product with Create API Product:

$ curl -H "Content-Type:application/json" -X POST -d
  "approvalType": "auto",
  "displayName": "Free API Product",
  "name": "weather_free",
  "proxies": [ "weatherapi" ],
  "environments": [ "test" ]
}' -u email:password

For a complete list of resources and methods, see the API reference.

As in other RESTful APIs, the Edge management API exposes capabilities as API resources. Each resource defines a set of methods that act on it.

Following RESTful principles, you can call HTTP GET, POST, PUT, and DELETE methods on any of the API resources.

  • GET: リソースのリストまたは特定のリソースのプロファイルを取得します。
  • POST: リソースを作成します。または、パラメータに渡され、リソースに対するアクションを実行します。例えば、OAuth アクセストークンを取り消すには、action=revoke パラメータを指定した POST メソッドを使用します。
  • PUT: 既存のリソースを更新します。
  • DELETE: 既存のリソースを削除します。


The path you'll use in management API requests concatenates the following:

  • A base path that includes your organization name. (You can locate your organization name under User Settings in the Edge management UI.)
  • An endpoint that points to the Edge resource you're accessing.

For example, if your organization name is "apibuilders", then every call you make to the management API will use the following base path:

組織に存在する API プロキシの一覧を取得するには、次に対する GET を呼び出します。

Many resources are scoped by environment. Two environments are provided by default: test and prod. For example, caches are scoped by environment. A shared cache called "mycache" is included by default in every environment.

You can list caches by calling GET on the cache resource as follows:


API では HTTP 基本認証が実行されます。ユーザーは常にアカウントのユーザー名とパスワードを渡す必要があります。ユーザー名とパスワードは、Base 64 に暗号化されたヘッダーとして、またはパラメータとして (以下に示す) HTTP クライアントに渡すことができます。次は、HTTP 基本認証ヘッダーの例です。

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

cURL コマンドの実行

Use an HTTP client to make requests to the management API. Many examples in the documentation provide sample API requests using cURL, a widely-used HTTP client. If you need to install cURL, you can download it from

マニュアルから端末に cURL コマンドを切り取り、貼り付けを行う場合は、コマンドの次の変数を Apigee アカウントの情報に置き換える必要があります。

  • email: Apigee アカウントのメール
  • password: Apigee アカウントのパスワード
  • myorg: Apigee 組織の名前
On Windows, make sure to download a version of cURL that includes the libcurl library. Also on Windows, you might need to use a flag to disable the trust check that cURL performs against the TLS/SSL certificate presented by the API Platform. You can do this by adding -k to each request you submit via cURL on the command line. This only disables the trust check and does not disable encryption. For example:
$ curl -k{org_name}/apis -u email:password

Edge のサンプルを使用している場合は、/setup/ ファイルの組織、ユーザー名、およびパスワードの値を設定します。こうすることで、簡素化された展開を実行し、各サンプル API プロキシで提供されているスクリプトを呼び出すことができます。詳細については、「サンプル API プロキシの使用」を参照してください。

管理 API に対する呼び出しでは、レスポンスでの gzip 圧縮がサポートされています。API 呼び出しで 'Accept-Encoding: gzip, deflate' を設定した場合は、1024 バイトより大きいレスポンスはすべて gzip 形式で返されます。

Example: Making requests of the management API

この例では、Edge に対する API 呼び出しを行います。この例の API 呼び出しでは、組織に存在するすべての API プロキシの名前の一覧が返されます。コンピュータの端末ウィンドウに次のコマンドをコピーして貼り付けます。

$ curl{org_name}/apis -u email:password

簡潔にするため、/organizations/o と短縮できます。例えば、ユーザー名が であり、パスワードが secret であり、組織内のアカウントの名称が apifactory である場合は、リクエストは次のようになります。

$ curl -u

レスポンスには、1 つの JSON 配列と 2 つの API プロキシ (すべての新規ユーザーに対してデフォルトで作成される) が含まれている必要があります。

[ "oauth", "weatherapi" ]

cURL には操作が簡単ないくつかのツールがあります。例えば、リクエストに関連付けられている HTTP ヘッダーをユーザーが確認する必要がある場合がよくあります。この HTTP リクエストに関する詳細を取得するには、cURL で提供されている -v フラグを使用できます。次に例を示します。

$ curl{org_name}/apis -u email:password -v

API プラットフォームからのレスポンスの HTTP ヘッダーを確認する必要があるものの、コンテンツは確認する必要がない場合に限り、-I フラグを使用できます。

$ curl{org_name}/apis -u email:password -I

Example: Returning XML

JSON はレスポンスメッセージのデフォルト形式です。XML が必要な場合は、JSON ではなく XML レスポンスを取得するため、次のように HTTP の Accept ヘッダーを追加することができます。

$ curl -H "Accept:text/xml" -u

XML でペイロードを POST または PUT する場合は、Content-type HTTP ヘッダーを使用します。

$ curl -H "Content-type:text/xml" -X POST -d \
 </XMLPayload> ' \ \


Every organization using Apigee Edge by default has at least two environments they can use to develop, test, and deploy APIs: test and prod.  Use the test environment to develop and test your APIs before making them publicly available. Only your internal developers can access APIs deployed to the test environment. Deploy your APIs to the prod environment to make them publicly available to app developers.


Edge API サービスには、エンドツーエンドのリクエストおよびレスポンスフローをデバッグできる Trace ツールが用意されています。トレースの結果には、リクエストヘッダー、レスポンスヘッダー、ペイロード、ポリシーの実行、変数の値、およびフロー中に発生した可能性のあるすべてのエラーが表示されます。


  • タイムスタンプ: 各ステップの実行にかかる時間を確認するには、タイムスタンプを使用します。タイムスタンプを比較すると、API 呼び出しを遅延させている実行に最も時間のかかっているポリシーを識別することができます。
  • ベースパス: ベースパスを確認することで、ポリシーによってメッセージが正しいサーバーに経路指定されていることを保証できます。
  • ポリシーの実行結果: この結果では、メッセージが XML から JSON に変換されているかどうか、メッセージがキャッシュされているかどうかなど、メッセージが予想通りに変更されているかどうかを確認できます。



  • Original request received from client: クライアントアプリからのリクエストの動詞と URI パス、ヘッダー、本文データ、およびクエリパラメータが表示されます。
  • Request sent to your backend service: API プロキシによってバックエンドサービスに送信されたリクエストメッセージが表示されます。
  • Response returned by the backend service: バックエンドサービスによって返されたレスポンスヘッダーとペイロードが表示されます。
  • Final response sent to client: レスポンスフローが実行された後にレスポンスメッセージが要求元のクライアントアプリに返されます。

Help or comments?