ابزار توسعه

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

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

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

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

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

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

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

https://apigee.com/edge

برای آموزش استفاده از رابط کاربری Edge، به Build your first API proxy مراجعه کنید.

لبه برای ابر خصوصی کاربری کلاسیک اج

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

http://ms-ip:9000

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

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

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

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

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

از API لبه استفاده کنید

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

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

برای فهرست کاملی از 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

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

محدودیت‌های API لبه

هر سازمان محدود به نرخ‌های فراخوانی Edge API زیر است:

  • ۱۰،۰۰۰ تماس در دقیقه برای سازمان‌هایی که از طرح‌های پولی استفاده می‌کنند
  • ۶۰۰ تماس در دقیقه برای سازمان‌های آزمایشی

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

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

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

خلاصه کردن آدرس‌های اینترنتی درخواست‌ها

هنگام ساخت 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 روی پاسخ‌ها پشتیبانی می‌کنند. اگر در فراخوانی‌های API خود 'Accept-Encoding: gzip, deflate' را تنظیم کنید، هر پاسخی که بزرگتر از 1024 بایت باشد، با فرمت gzip برگردانده می‌شود.

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

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 پشتیبانی نمی‌کند. در نتیجه، شما فقط می‌توانید پاسخ‌هایی با فرمت JSON را با acurl دریافت کنید.

برای استفاده prettyprint برای پاسخ JSON، می‌توانید از کتابخانه پایتون json.tool استفاده کنید: 

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

اشکال‌زدایی و آزمایش

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

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

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

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

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

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

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