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.

API 製品 (product) の作成

API 製品は Apigee Edge 管理 UI (https://enterprise.apigee.com) または管理 API で作成できます。この手順では、管理 UI の場合の手順を示します。API の場合の手順は、「Using the Edge management API to Publish APIs」を参照してください。

For an overview of API products, see What is an API product?.

Watch this video to learn how to create an API product.

API 製品が正しく機能するように、次を実行します。

  • API プロキシに適切なセキュリティポリシー (Verify API Key や OAuth v2.0 など) を含めます。API 製品は、API キーおよび/または OAuth アクセストークンを使用して、API アクセスを強制します。詳細については、「API keys」と「OAuth home」を参照してください。
  • Add API proxies and/or resources to your API product to restrict access. Otherwise, any app associated with the API product will be able to make calls to any API in your Edge organization.

Understand key concepts

Review the following key concepts before you create your API products.

API keys

組織内のデベロッパのアプリを登録するとき、アプリを 1 つ以上の API 製品に関連付ける必要があります。アプリを 1 つ以上の API 製品と対にした結果として、Edge は、アプリに一意のコンシューマキーを割り当てます。アプリが API 製品内の API リソースへのリクエストを実行するとき、リクエストにはその一意の API キーを含める必要があります。

API key enforcement doesn't happen automatically. You must enforce API key checking in your API proxies with a policy, such as the Verify API Key policy. Without some type of key enforcement policy, anyone can make calls to your APIs. For more information, see Verify API Key policy.

結論として、Edge からキーが自動的に生成されますが、API でキー確認を強制する必要があります。

Automatic versus manual approval

By default, all key requests to an API product from an app are automatically approved. You can instead choose to approve keys manually. If you set this option in the Edge management UI when creating the product, you will have to approve key requests that come in from any app that adds the API product. For more information, see Register apps and manage API keys.

クォータ

クォータは、バックエンドサーバーを高トラフィック用に保護し、製品ラインを差別化できます。例えば、高クォータのリソースをプレミアム製品としてバンドルし、クォータがそれよりも少ない同じバンドルをベーシック製品として使用できます。クォータは、製品が特に人気がある場合にサーバーがあふれることを防ぐのに役立つことがあります。

製品上でクォータ制限を設定しても、クォータは自動的には強制されません。これは、クォータポリシーで参照できるデフォルトの制限にすぎません。次に、製品上でクォータポリシーが参照するクォータを設定する利点をいくつか示します。

  • クォータポリシーは、API 製品のすべての API プロキシで統一された設定を使用できます。
  • API 製品上でクォータ設定に対して実行時の変更を実行でき、その値を参照するクォータポリシーに、更新されたクォータ値が自動的に設定されます。

クォータの構成については、「Quota policy」を参照してください。クォータポリシーでの製品クォータ設定の使用については、https://community.apigee.com/questions/1488/how-do-the-quota-settings-on-an-api-product-intera.html を参照してください。

スコープ

追加レベルのセキュリティとして、製品を通じて送信されるアクセストークンに存在する必要がある OAuth スコープをカンマ区切りリスト形式で定義できます。製品を作成するときは、組織が使用するすべてのスコープを認識している必要があります。製品に追加するスコープは既存のスコープと一致する必要があります。そうでない場合、その製品はセキュアではなくなります。

For more information about using scopes with Edge OAuth policies, see Working with OAuth2 scopes.

API 製品の作成

You can create an API product in the Apigee Edge management UI at https://enterprise.apigee.com or with the management API. This procedure shows the management UI version. For the API version, (see Using the Edge management API to Publish APIs).

API 製品を作成するには、次の手順に従います。

  1. Login to the Edge management UI at https://enterprise.apigee.com. (You can obtain a free account at https://login.apigee.com/sign_up.)
  2. Click the Publish tab, then Products.
  3. 「(+) Product」ボタンをクリックします。
  4. 「Add Products」ページで、Name を入力します。これが製品の内部名になります。この名前は、いったん製品が作成されると変更できません。名前では、特殊文字を使用できません。 
  5. Enter a Display Name. The display name displays in the UI. The Display Name field is automatically populated using the contents of the Name field, but you can edit it. You can change the display name at any time by editing the product. You can use special characters in the display  name. 
  6. Optionally, enter a Description for the API product. 
  7. 製品に 1 つ以上の API プロキシを追加します。「+API Proxy」をクリックします。
    これで、一覧表示されている API プロキシへのアクセスが制限されます。この手順の後の方で、リソースを構成します。
    API プロキシを選択しなかった場合、製品に関連付けられているあらゆるアプリが、組織 (organization) 全体のあらゆる API への呼び出しを実行できます。
  8. Environment: 製品でアクセスを許可する環境を選択します。例えば、内部に公開されている製品の場合は test 環境を、公に公開されている製品の場合は prod 環境を選択します。
    The environments you specify here restrict access to API proxies based on where they are deployed. For example, if API proxy A is deployed to both the test and prod environments, but the Product only has the test environment selected, then an API call for the corresponding Developer App only allows access to API proxy A deployed in the test environment.
    環境 (environment) を選択しなかった場合、製品では、すべての環境へのアクセスが許可されます。
  9. 「Access」レベルを選択します。
    • Public - デベロッパは、Developer Services Portal でデベロッパアプリを作成または変更するとき、Public の製品を表示および選択できます。
    • Internal only または Private - 2 つのオプションの間に機能的な違いはありません。API 製品は、internal only または private の場合、Developer Services Portal に表示されません。デベロッパが製品を使用できるようにするには、管理 UI または管理 API でデベロッパアプリに製品を手動で追加する必要があります。これを行うと、Developer Services Portal でアプリに関連付けられている製品がデベロッパに表示されます。
  10. Select a Key Approval Type as Automatic or Manual.
    If you select automatic key approval, all key requests that come in from any app that uses this API product are automatically approved. If you select manual key approval, you will have to approve key requests that come in from any app that uses this API product. To manually approve keys:
    • UI: Publish > Developer Apps > developer_app > click Edit to edit the app > Approve
    • API: Use the Developer App Keys API.
  11. クォータの「Quota」制限を入力しても、製品を通じて実行できる呼び出しの回数に対する制限は自動的には強制されません。詳細については、上記の「クォータ」セクションを参照してください。

    クォータポリシーから参照するクォータ制限を入力します。

  12. Optionally, if you are using OAuth with the API product, enter the Allowed OAuth Scopes that you want the product to allow (such as 'Read' or any other scopes that apps will send with their API calls). You can specify multiple scopes as a comma-separated list. 

    For more about scopes, see Working with OAuth2 scopes.
  13. In the Resources section, add an API Proxy, Revision, and Resource Path to the API product.

    See also this Apigee Community article: Making sense of API Product configuration

    Adding Resource Paths lets you further restrict API access with relation to the API proxies included in the product. For example, let's say you add a "music" API proxy to the product with a base path of /music. That means the product allows calls to /music.

    However, you want the product to allow access to only the venues resource, which has a URI of /music/venues. By adding a /venues Resource Path to the product, the product allows calls to only that URI. For example, calls to /music/venues?name=paramount go through, but calls to /music/artists?name=Jack%Johnson get rejected.

    You can add Resource Paths either by selecting one from an existing API proxy API Proxy, Revision, and a Resource Path (then click Import Resource), or by clicking +Custom Resource and adding a free-form resource pattern.
    特定のパスを選択したり、「/」のようなリソースパスを指定してベースパスとすべてのサブパスを指定したりできます。

    Resource Path は、ワイルドカード /** や /* もサポートしています。アスタリスク 2 個のワイルドカードは、ベースパスのすべてのサブ URI がサポートされ、ベースパスはサポートされないことを示します。アスタリスク 1 個は、ベースパスから 1 レベル下の URI のみがサポートされることを示します。

    詳細については、「リソースパス「/」、「/*」、「/**」の動作を構成する」を参照してください。
  14. (Optional) You can also add up to 18 custom attributes to an API product. Custom attributes are key/value pairs that can be used in many ways, including helping control API proxy execution. For example, you could create a custom attribute called deprecated with a value of true or false. In your API proxy flow, you could check the value of the API product's deprecated attribute (for example, using the verifyapikey.{policy_name}.apiproduct.deprecated variable that is automatically available after you create the custom attribute). If its value is true (deprecated), you can throw an error with the Raise Fault policy.
  15. 製品を保存します。

Editing an API product

To improve performance, API product information, such as resource path definitions, are cached for a short period of time (approximately five minutes). As a result, edits that you make to an API product may not take effect immediately.

To edit an API product:

  1. Edge 管理 UI (https://enterprise.apigee.com) にログインします。
  2. Click the Publish tab, then Products.
  3. Click the name of the API product that you want to edit.
  4. Click Edit on the API product page.
  5. Edit the fields, as required.
  6. 「Save」をクリックします。 

リソースパス「/」、「/*」、「/**」の動作を構成する

The following table describes the default behavior of an API product for different Resource Paths. In this example, the API proxy has a base path of /v1/weatherapikey. The API product resource path applies to the path suffix after the base path.

See also this Apigee Community article: Making sense of API Product configuration

リクエストパス Allowed for / Allowed for /* Allowed for /** Allowed for /*/2/**

/v1/weatherapikey

Y

N

N

N

/v1/weatherapikey/

Y

N

N

N

/v1/weatherapikey/1

Y

Y

Y

N

/v1/weatherapikey/1/

Y

Y

Y

N

/v1/weatherapikey/1/2

Y

N

Y

N

/v1/weatherapikey/1/2/

Y

N

Y

Y

/v1/weatherapikey/1/2/3/

Y

N

Y

Y

/v1/weatherapikey/1/a/2/3/

Y

N

Y

N

デフォルトでは、API 製品でのResource Path「/」は、ベースパスとすべてのサブ URI をサポートしています、例えば、API プロキシの Base Path/v1/weatherapikey の場合、API 製品は、/v1/weatherapikey へのリクエストをサポートし、/v1/weatherapikey/forecastrss/v1/weatherapikey/region/CAなどへのリクエストもサポートします。

Resource Path「/」が API プロキシの Base Path にのみ対応するように、デフォルトを変更できます。これは、API 製品が「/」以外のあらゆる設定の URI へのアクセスを許可しないことを意味します。この変更を実行した場合、上記の表は、「「/」の場合に許可される?」の下の初めの 2 行のみに「Y」が記載されることになります。

マネタイズ: 製品がマネタイズで使用される場合、トランザクション記録ポリシーの定義に製品リソースパスが使用される場所では、明示的に「/**」を使用してください。マネタイズでは、「/」がベースパスのみとして扱われ、「/**」はそのように扱われません。 

デフォルトを変更するには、システム管理者は、組織のfeatures.isSingleForwardSlashBlockingEnabledプロパティの値を true に設定する必要があります。クラウドのお客様は、Apigee Support に対してそのリクエストを実行できます。

Apigee Edge for Private Cloud のお客様は、次のフォームでリクエストを実行して、組織のプロパティを設定できます。

curl -u username:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization name='myorg' type='trial'> \
<Properties> \
<Property name='features.isSingleForwardSlashBlockingEnabled'>true</Property> \
<!-- other existing org properties here --> \
</Properties> \
</Organization>"

Be sure to include other existing organization properties in this API call. If you don't, the old properties are wiped out and replaced by the property set in this call.

リソースの削除 

API 製品に追加したリソースを削除できます。これは、リソースに不具合があったり、さらに開発が必要であったりした場合に実行できます。削除されると、そのリソースは API 製品の一部ではなくなります。その API 製品を使用しているあらゆるアプリは、削除されたリソースにアクセスできなくなります。削除されたリソースは、製品から削除されますが、システムからは削除されません。したがって、他の製品で使用することはできます。

リソースを削除するには、次の手順に従います。

  • 製品詳細ウィンドウの「API Resource Paths for Product」セクションで、無効にするリソースを探し、「Actions」列の「Delete」をクリックします。

     

 

Help or comments?