ابزار توسعه

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید .
اطلاعات

به عنوان یک ارائه‌دهنده خدمات، APIهایی را برای مصرف برنامه‌های مشتری توسعه می‌دهید. برای ایجاد، پیکربندی و نگهداری پراکسی‌های API و محصولات API، می‌توانید از UI استفاده کنید یا درخواست‌های HTTP را برای دسترسی به خدمات RESTful به APIها ارسال کنید، همانطور که در بخش‌های زیر توضیح داده شده است.

از رابط کاربری Edge استفاده کنید

رابط کاربری Apigee Edge ابزاری مبتنی بر مرورگر است که می‌توانید از آن برای ایجاد، پیکربندی و مدیریت پراکسی‌های API و محصولات API استفاده کنید. زیرمجموعه ای از وظایف را فقط می توان با استفاده از API انجام داد.

جدول زیر نحوه دسترسی به رابط کاربری Edge را شرح می دهد:

محصول نام رابط کاربری دسترسی به URL
لبه رابط کاربری لبه

برای دسترسی به رابط کاربری Edge، از URL زیر استفاده کنید:

https://apigee.com/edge

برای آموزش استفاده از رابط کاربری Edge، به ساخت اولین پروکسی API خود مراجعه کنید.

Edge برای Private Cloud Classic Edge UI

برای دسترسی به رابط کاربری Edge برای Edge for Private Cloud، از URL زیر استفاده کنید:

http://ms-ip:9000

جایی که ms-ip آدرس IP یا نام DNS گره مدیریت سرور است.

با استفاده از رابط کاربری Edge، می توانید:

  • با ویرایش کد و ردیابی جریان های درخواست از طریق پراکسی های خود، پراکسی های API ایجاد کنید.
  • محصولات API ایجاد کنید که پراکسی‌ها را برای قرار گرفتن در معرض درخواست‌های مشتری قرار می‌دهند.
  • توسعه دهندگان و برنامه های توسعه دهنده را مدیریت کنید.
  • محیط های آزمایش و تولید خود را پیکربندی کنید.
  • برنامه های JavaScript و Node.js را پیاده سازی کنید.

تصویر زیر ویرایشگر پراکسی API را در رابط کاربری نشان می‌دهد که می‌توانید برای ایجاد و پیکربندی یک پراکسی API از آن استفاده کنید:

برگه Develop را نشان می دهد که در ویرایشگر پراکسی API در رابط کاربری Edge انتخاب شده است.

از Edge API استفاده کنید

می توانید از Edge API برای مدیریت منابع API خود استفاده کنید. APIها همچنین دسترسی به قابلیت‌های سطح پایینی را فراهم می‌کنند که توسط UI در معرض نمایش قرار نمی‌گیرند.

نقاط پایانی API اغلب داده های حاوی اطلاعات پیکربندی را می گیرند و برای دسترسی به آنها از شما می خواهند که اطلاعات احراز هویت مانند نام کاربری و رمز عبور را ارسال کنید. با پیروی از اصول RESTful، می‌توانید روش‌های HTTP GET ، POST ، PUT و DELETE را در هر یک از منابع API فراخوانی کنید.

برای فهرست کامل Apigee Edge APIها، به مرجع Apigee Edge مراجعه کنید.

مسیر پایه 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

بسیاری از منابع بر اساس محیط در نظر گرفته شده اند. دو محیط به طور پیش فرض ارائه شده است: test و prod. به عنوان مثال، کش ها بر اساس محیط محدوده بندی می شوند. یک کش مشترک به نام "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 زیر است:

  • 10000 تماس در دقیقه برای سازمان هایی که دارای طرح های پولی هستند
  • 600 تماس در دقیقه برای سازمان های آزمایشی

کدهای وضعیت HTTP 401 و 403 در این محدودیت حساب نمی شوند. هر تماسی که بیش از این محدودیت‌ها باشد، کد وضعیت 429 Too Many Requests برمی‌گرداند.

نکاتی برای کار با API های Edge

این بخش تکنیک هایی را توضیح می دهد که کار با API های Edge را آسان تر می کند.

مخفف کردن URL های درخواست

هنگامی که URL درخواست خود را برای API های Edge می سازید، می توانید از اختصارات زیر استفاده کنید:

  • /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 استفاده کنید. بسیاری از نمونه‌های موجود در اسناد، درخواست‌های API نمونه را با استفاده از curl ، یک کلاینت HTTP پرکاربرد، ارائه می‌کنند. اگر نیاز به نصب curl دارید، می توانید آن را از http://curl.haxx.se دانلود کنید.

تماس‌های API از فشرده‌سازی gzip در پاسخ‌ها پشتیبانی می‌کنند. اگر 'Accept-Encoding: gzip, deflate' را در تماس های API خود تنظیم کنید، هر پاسخی بیش از 1024 بایت در قالب gzip برگردانده می شود.

قالب بندی درخواست ها و پاسخ های XML و JSON

Edge API داده ها را به صورت پیش فرض به صورت JSON برمی گرداند. برای بسیاری از درخواست‌ها، می‌توانید پاسخ را به‌عنوان XML دریافت کنید. برای انجام این کار، همانطور که در مثال زیر نشان داده شده است، سربرگ Accept request را روی 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، از هدر HTTP Content-type استفاده کنید:

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ها دارد: "test" و "prod". از محیط "تست" برای توسعه و آزمایش APIهای خود قبل از در دسترس قرار دادن آنها برای عموم استفاده کنید. فقط توسعه دهندگان داخلی شما می توانند به APIهای مستقر در محیط آزمایش دسترسی داشته باشند. API های خود را در محیط "prod" مستقر کنید تا آنها را به صورت عمومی در اختیار توسعه دهندگان برنامه قرار دهید.

اشکال زدایی و تست

Apigee یک ابزار ردیابی را ارائه می دهد که به شما امکان می دهد جریان های درخواست و پاسخ سرتاسر را اشکال زدایی کنید. نتایج ردیابی سرصفحه‌ها و بارهای درخواست و پاسخ، اجرای خط‌مشی، مقادیر متغیر و هر گونه خطایی را که ممکن است در طول جریان رخ داده باشد را نمایش می‌دهد.

نکات کلیدی داده برای استفاده در عیب یابی:

  • مهر زمانی : از مهرهای زمانی استفاده کنید تا ببینید هر مرحله چقدر طول می کشد تا اجرا شود. مقایسه مُهرهای زمانی به شما کمک می‌کند خط‌مشی‌هایی را جدا کنید که اجرای آنها طولانی‌ترین زمان را می‌برد و باعث کاهش سرعت تماس‌های API شما می‌شود.
  • مسیر پایه : با تأیید مسیر پایه، می‌توانید مطمئن شوید که یک خط‌مشی پیام را به سمت درست سرور هدایت می‌کند.
  • نتایج اجرای خط‌مشی : این نتایج به شما امکان می‌دهد ببینید آیا پیام همانطور که انتظار می‌رود تغییر می‌کند، مثلاً پیام از XML به JSON تبدیل می‌شود یا اینکه پیام در حافظه پنهان ذخیره می‌شود.

شکل زیر نتایج ردیابی را نشان می دهد:

برگه Trace را که در ویرایشگر پروکسی API در رابط کاربری Edge انتخاب شده است نشان می دهد.

هر جلسه Trace به مراحل اصلی زیر تقسیم می شود:

  • درخواست اصلی دریافت شده از مشتری : فعل و مسیر URI درخواست را از برنامه مشتری، سرصفحه ها، داده های بدنه و پارامترهای پرس و جو نمایش می دهد.
  • درخواست ارسال شده به سرویس پشتیبان شما : پیام درخواستی را که توسط پروکسی API به سرویس باطن ارسال شده است نمایش می دهد.
  • پاسخ برگردانده شده توسط سرویس باطن : سرصفحه های پاسخ و بار بازگشتی توسط سرویس باطن را نمایش می دهد.
  • پاسخ نهایی به مشتری ارسال شد: پس از اجرای جریان پاسخ، پیام پاسخ به برنامه مشتری درخواست کننده باز می گردد.