您正在查看的是 Apigee Edge 文档。
转到 Apigee X 文档。 信息
作为服务提供商,您可以开发供客户端应用使用的 API。如需创建、配置和维护 API 代理和 API 产品,您可以使用界面或向 API 发出 HTTP 请求以访问 RESTful 服务,如以下部分所述。
使用 Edge 界面
Apigee Edge 界面是一款基于浏览器的工具,可用于创建、配置和管理 API 代理和 API 产品。部分任务只能使用 API 来完成。
下表介绍了如何访问 Edge 界面:
产品 | 界面名称 | 访问网址 |
---|---|---|
Edge | Edge 界面 | 如需访问 Edge 界面,请使用以下网址: https://apigee.com/edge 如需查看有关使用 Edge 界面的教程,请参阅构建您的第一个 API 代理。 |
适用于私有云的 Edge | 传统版 Edge 界面 | 如需访问适用于私有云的 Edge 界面,请使用以下网址: http://ms-ip:9000 其中,ms-ip 是管理服务器节点的 IP 地址或 DNS 名称。 |
使用 Edge 界面,您可以:
- 通过修改代码和通过代理跟踪请求流来创建 API 代理。
- 创建捆绑了代理以向客户端请求公开的 API 产品。
- 管理开发者和开发者应用。
- 配置测试和生产环境。
- 实现 JavaScript 和 Node.js 应用。
下图显示了界面中可用于创建和配置 API 代理的 API 代理编辑器:
使用 Edge API
您可以使用 Edge API 来管理 API 资源。这些 API 还提供对界面未公开的低级别功能的访问权限。
API 端点通常接受包含配置信息的数据,并要求您传递用户名和密码等身份验证信息才能访问这些端点。按照 RESTful 原则,您可以对任何 API 资源调用 HTTP GET
、POST
、PUT
和 DELETE
方法。
如需查看 Apigee Edge API 的完整列表,请参阅 Apigee Edge API 参考文档。
了解 Edge API 基本路径
您将在 API 请求中使用的路径将连接以下项:
- 包含组织名称的基本路径。例如:
https://api.enterprise.apigee.com/v1/organizations/org_name
- 指向您正访问的 Edge 资源的端点。
例如,如果您的组织名称是 apibuilders
,那么您对 API 的每次调用都将使用以下基本路径:
https://api.enterprise.apigee.com/v1/organizations/apibuilders
要检索您组织中的 API 代理列表,您可以对以下代码调用 GET:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis
许多资源都是按环境划分的。默认提供两种环境:测试和生产环境。例如,缓存按环境划分范围。默认情况下,每个环境中都会包含一个名为“mycache”的共享缓存。
您可以通过对缓存资源调用 GET 来列出缓存,如下所示:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches
身份验证访问权限
调用 API 时,您必须向 API 服务器验证身份。您可以通过以下任一方式来执行此操作:
此外,Apigee 建议您使用双重身份验证,如为 Apigee 帐号启用双重身份验证中所述。
Edge API 限制
每个组织的 Edge API 调用速率上限如下:
- 采用付费方案的组织每分钟 10,000 次通话
- 试用组织每分钟 600 次通话
HTTP 状态代码 401
和 403
不计入此限制。超出这些限制的任何调用都将返回 429 Too Many Requests
状态代码。
有关使用 Edge API 的提示
本部分介绍了一些可让您更轻松地使用 Edge API 的技巧。
缩略请求网址
构建指向 Edge API 的请求网址时,您可以使用以下缩写:
/e = /environments
/o = /organizations
/r = /revisions
如果您使用缩写,必须保持一致。也就是说,缩写路径中的所有元素(如上例所示)或不含任何元素。 在同一路径中同时使用完整元素和缩写元素会导致错误。
例如:
THIS: https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments CAN BE MUCH SHORTER: https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments
执行 curl 命令
使用 HTTP 客户端向 API 发出请求。文档中的许多示例都提供了使用 curl
(一种广泛使用的 HTTP 客户端)的示例 API 请求。如果您需要安装 curl
,可以从 http://curl.haxx.se 下载。
调用该 API 时,支持对响应进行 gzip 压缩。如果您在 API 调用中设置 'Accept-Encoding: gzip, deflate'
,则任何超过 1024 个字节的响应都会以 gzip 格式返回。
设置 XML 和 JSON 请求及响应的格式
默认情况下,Edge API 以 JSON 格式返回数据。对于许多请求,您可以改为以 XML 的形式发回响应。为此,请将 Accept
请求标头设置为 application/xml
,如以下示例所示:
curl -H "Authorization: Bearer `get_token`" \ -H "Accept: application/xml" \ https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ | xmllint --format -
响应应如下所示:
<List> <Item>SOAP-Message-Validation-1</Item> <Item>Spike-Arrest-1</Item> <Item>XML-to-JSON-1</Item> </List>
请注意,此示例使用 prettyprint
来显示结果,方法是通过 xmllint
传递响应。
acurl
实用程序不支持 Accept
标头。因此,您只能使用 acurl
获取 JSON 格式的响应。
如需使用 prettyprint
获取 JSON 响应,您可以使用 json.tool
Python 库:
curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ -H "Accept: application/json" \ -H "Authorization: Bearer `get_token`" \ | python -m json.tool
以下提供了一个响应示例:
[ "SOAP-Message-Validation-1", "Spike-Arrest-1", "XML-to-JSON-1" ]
对于 XML,您可以使用 xmllint
:
curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -
在 XML 中 POST 或 PUT 载荷时,请使用 Content-type
HTTP 标头:
acurl -H "Content-type:text/xml" -X POST -d \ '<XMLPayload> </XMLPayload> ' \ https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address
部署环境
默认情况下,使用 Apigee Edge 的每个组织都至少有两个可用于开发、测试和部署 API 的环境:“测试”和“生产”。在公开提供您的 API 之前,请使用“测试”环境开发和测试 API。只有您的内部开发者可以访问部署到测试环境的 API。将您的 API 部署到“prod”环境,以向应用开发者公开这些 API。
调试和测试
Apigee 提供了跟踪工具,可用于调试端到端请求和响应流程。跟踪记录结果会显示请求和响应标头和载荷、政策执行情况、变量值以及流程中可能发生的任何错误。
问题排查过程中使用的关键数据点:
- 时间戳:使用时间戳了解执行每个步骤所用的时间。比较时间戳有助于您找出执行时间最长、拖慢 API 调用速度的政策。
- 基本路径:通过验证基本路径,您可以确保政策将消息路由到正确的服务器。
- 政策执行结果:您可以通过这些结果了解消息是否按预期发生更改,例如消息是否正在从 XML 转换为 JSON,或者消息是否正在缓存。
下图显示了轨迹结果:
每个跟踪会话都细分为以下主要步骤:
- 从客户端接收的原始请求:显示来自客户端应用的请求的动词和 URI 路径、标头、正文数据和查询参数。
- 发送到后端服务的请求:显示 API 代理发送到后端服务的请求消息。
- 后端服务返回的响应:显示后端服务返回的响应标头和载荷。
- 发送到客户端的最终响应:响应流执行后返回给发出请求的客户端应用的响应消息。