פרסום ממשקי ה-API

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

לפרסם ממשקי API בפורטל כדי שמפתחי אפליקציות יוכלו להשתמש בהם, כפי שמתואר בסעיפים הבאים.

סקירה כללית של פרסום API

תהליך הפרסום של ממשקי API בפורטל כולל שני שלבים:

1. בוחרים את מוצר ה-API שרוצים לפרסם בפורטל.
2. אפשר לעבד את מאמרי העזרה של ה-API מתוך snapshot של מסמך OpenAPI או של סכימת GraphQL כדי לאפשר למפתחי אפליקציות ללמוד על ממשקי ה-API שלכם. (מידע נוסף על תמונות מצב זמין במאמר מהי תמונת מצב?)

מה מפורסם בפורטל?

SmartDocs (OpenAPI)

כשמפרסמים ממשק API באמצעות מסמך OpenAPI, מסמכי העזר של SmartDocs API מתווספים לפורטל.

המפתחים יכולים לעיין במסמכי העזרה של SmartDocs API ולהשתמש בחלונית Try this API כדי לשלוח בקשת API ולהציג את הפלט. כדאי לנסות את ה-API הזה עם נקודות קצה לא מאובטחות או עם נקודות קצה מאובטחות באמצעות שימוש בסיסי, מפתח API או אימות OAuth, בהתאם לשיטת האבטחה שהוגדרה במסמך OpenAPI. ב-OAuth יש תמיכה בתהליכים הבאים: קוד הרשאה, סיסמה ופרטי כניסה של לקוח.

לוחצים על כדי להרחיב את החלונית 'אני רוצה לנסות את ה-API הזה'. החלונית המורחבת מאפשרת לכם לצפות בדוגמאות של קריאת curl ושל קוד בפורמטים שונים, כמו HTTP, Python, Node.js ועוד, כפי שמוצג בהמשך.

סייר GraphQL

כשמפרסמים API באמצעות סכימת GraphQL, הסייר של GraphQL מתווסף לפורטל שלכם. GraphQL Explorer הוא מגרש משחקים אינטראקטיבי להרצת שאילתות מול ה-API שלכם. הניתוח מבוסס על GraphiQL, יישום עזר של סביבת הפיתוח המשולבת של GraphQL שפותחה על ידי קרן GraphQL.

מפתחים יכולים להשתמש ב- GraphQL Explorer כדי לעיין בתיעוד האינטראקטיבי המבוסס על סכימה, לבנות ולהריץ שאילתות, להציג תוצאות שאילתות ולהוריד את הסכימה. כדי לאבטח את הגישה ל-API, מפתחים יכולים להעביר כותרות הרשאות בחלונית Request Headers (כותרות של בקשות).

מידע נוסף על GraphQL זמין בכתובת graphql.org.

מהי תמונת מצב?

כל מסמך OpenAPI או GraphQL משמש כמקור האמת לאורך מחזור החיים של API. אותו מסמך משמש בכל שלב במחזור החיים של ה-API, מפיתוח ועד פרסום ומעקב. כשאתם משנים מסמך, אתם צריכים להבין את ההשפעה של השינויים על ה-API שלכם בשלבים אחרים במחזור החיים, כפי שמתואר בקטע מה קורה אם משנים מסמך?

כשמפרסמים את ה-API, מצלמים תמונת מצב של מסמכי OpenAPI או GraphQL כדי לעבד את מאמרי העזרה של ה-API. תמונת המצב הזו מייצגת גרסה ספציפית של המסמך. אם תשנו את המסמך, תוכלו לצלם תמונת מצב נוספת של המסמך כדי לשקף את השינויים האחרונים במסמכי העזרה של ה-API.

מידע על כתובות URL לקריאה חוזרת (callback)

אם באפליקציות שלך מחייבות כתובת URL לקריאה חוזרת, למשל, בזמן השימוש בקוד ההרשאה מסוג OAuth 2.0 (שנקרא בדרך כלל 'OAuth תלת-שלבי'), אפשר לדרוש מהמפתחים לציין כתובת URL לקריאה חוזרת (callback) כשהם רושמים את האפליקציות שלהם. כתובת ה-URL לקריאה חוזרת (callback) מציינת בדרך כלל את כתובת ה-URL של אפליקציה שמוגדרת לקבל קוד הרשאה מטעם אפליקציית הלקוח. מידע נוסף זמין במאמר הטמעת סוג הענקת קוד ההרשאה.

אתם יכולים להגדיר אם לדרוש כתובת URL לקריאה חוזרת (callback) במהלך רישום האפליקציה כשמוסיפים ממשק API לפורטל. אפשר לשנות את ההגדרה הזו בכל שלב, כפי שמתואר במאמר ניהול כתובת URL לקריאה חוזרת (callback) ב-API.

במהלך הרישום של אפליקציה, המפתחים חייבים להזין כתובת URL לקריאה חוזרת (callback) עבור כל ממשקי ה-API שדורשים אותה, כפי שמתואר במאמר רישום אפליקציות.

הגדרת שרת ה-proxy ל-API כך שיתמוך ב'ניסיון ה-API הזה'

לפני פרסום ממשקי ה-API באמצעות מסמך OpenAPI, עליך להגדיר את שרת ה-proxy של ה-API כך שיתמוך בשליחת בקשות בחלונית 'נסה את ממשק ה-API הזה' במשאבי העזרה של SmartDocs API:

• הוספת תמיכה ב-CORS לשרתי proxy ל-API כדי לאכוף בקשות ממקורות שונים בצד הלקוח

  CORS הוא מנגנון סטנדרטי שמאפשר לקריאות XMLHttpRequest (XHR) של JavaScript שמתבצעות בדף אינטרנט ליצור אינטראקציה עם משאבים מדומיינים שאינם ממקור. CORS הוא פתרון מקובל למדיניות המקור הזהה. שנאכפת על ידי כל הדפדפנים.

• עדכון ההגדרה של שרת ה-proxy ל-API אם משתמשים באימות בסיסי או ב-OAuth2

הטבלה הבאה מסכמת את דרישות התצורה של שרתי proxy ל-API כדי לתמוך בחלונית 'התנסות עם ה-API הזה' במשאבי העזרה של SmartDocs API בהתבסס על הגישה לאימות.

לקטלוג ממשקי API

כדי להציג את קטלוג ממשקי ה-API: 1. בוחרים באפשרות פרסום > פורטלים ובוחרים את הפורטל. 2. לוחצים על קטלוג API בדף הבית של הפורטל. לחלופין, אפשר לבחור קטלוג API בתפריט הנפתח של הפורטל בסרגל הניווט העליון.

בכרטיסייה 'ממשקי API' בקטלוג ה-API מוצגת רשימה של ממשקי ה-API שנוספו לפורטל שלכם.

כפי שמודגש באיור הקודם, הכרטיסייה 'ממשקי API' מאפשרת לך:

• הצגת הפרטים של ממשקי ה-API שזמינים בפורטל שלך
• הוספת API לפורטל
• כדי לערוך API בפורטל, מבצעים אחת או יותר מהמשימות הבאות:
  • ניהול תמונת מצב של מסמך המשויך למוצר API כדי לעדכן את מאמרי העזרה של ה-API
  • פרסום או ביטול הפרסום של API בפורטל
  • ניהול הרשאות הגישה של API בפורטל:
  • ניהול כתובת ה-URL לקריאה חוזרת (callback) ב-API
  • ניהול התמונה של כרטיס API
  • תיוג API באמצעות קטגוריות
  • עריכת השם והתיאור של ה-API
• הסרת API מהפורטל
• ניהול הקטגוריות שמשמשות למציאת ממשקי API קשורים
• זיהוי מהיר של מפרטים לא עדכניים או כאלה שנמחקו מחנות המפרט
• זיהוי מהיר של 'יתומים' ממשקי API שמוצר ה-API המשויך שלהם הוסר מ-Edge, צריך ליצור מחדש את מוצר ה-API או למחוק את ה-API מהפורטל

הוספת ממשק API לפורטל

כך מוסיפים ממשק API לפורטל:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.

3. לוחצים על הסימן +.

   תיבת הדו-שיח 'הוספת מוצר API לקטלוג' מופיעה.

4. בוחרים את מוצר ה-API שרוצים להוסיף לפורטל.

5. לוחצים על הבא. דף הפרטים של ה-API יוצג.

6. מגדירים את תוכן מסמכי העזרה של ה-API ואת החשיפה שלו בפורטל:

   שדה	תיאור
   פורסם	בוחרים באפשרות פורסם כדי לפרסם את ה-API בפורטל. מבטלים את הסימון של התיבה אם לא רוצים לפרסם את ה-API. אפשר לשנות את ההגדרה מאוחר יותר, כמו שמתואר במאמר פרסום או ביטול פרסום של API בפורטל.
   כותרת לתצוגה	מעדכנים את הכותרת של ה-API שמוצגת בקטלוג. כברירת מחדל, נעשה שימוש בשם המוצר של ה-API. אפשר לשנות את השם המוצג מאוחר יותר, כמו שמתואר במאמר עריכת השם המוצג והתיאור.
   התיאור המוצג	מעדכנים את תיאור ה-API שמוצג בקטלוג. כברירת מחדל, נעשה שימוש בתיאור המוצר של ה-API. תוכלו לשנות את התיאור לתצוגה בשלב מאוחר יותר, כמו שמתואר במאמר עריכת השם והתיאור לתצוגה.
   דרישה מהמפתחים לציין כתובת URL לקריאה חוזרת (callback)	כדאי להפעיל את האפשרות הזו אם רוצים לדרוש ממפתחי האפליקציות לציין כתובת URL לקריאה חוזרת (callback). אפשר להוסיף או לעדכן את כתובת ה-URL לקריאה חוזרת בשלב מאוחר יותר, כפי שמתואר במאמר ניהול כתובת ה-URL לקריאה חוזרת (callback) ב-API.
   תיעוד ממשק API	כדי להשתמש במסמך OpenAPI: בוחרים באפשרות OpenAPI document. לוחצים על בחירת מסמך. יש לבצע אחת מהפעולות הבאות: לוחצים על הכרטיסייה המפרט שלי ובוחרים מפרט מחנות המפרט. לוחצים על הכרטיסייה העלאת קובץ ומעלים קובץ. לוחצים על הכרטיסייה ייבוא מכתובת URL ומייבאים מפרט מכתובת URL. לוחצים על בחירה. כדי להשתמש בסכימת GraphQL: בוחרים באפשרות ChartQL Schema. לוחצים על בחירת מסמך. מנווטים לסכימת GraphQL ובוחרים בה. לוחצים על בחירה. לחלופין, אפשר לבחור באפשרות אין תיעוד ולהוסיף תיעוד מאוחר יותר אחרי שמוסיפים את ה-API, כמו שמתואר במאמר ניהול תמונת המצב של המסמך.
   הרשאות גישה ל-API	אם לא נרשמתם לגרסת הבטא של התכונה 'ניהול קהלים', אתם צריכים לבחור אחת מהאפשרויות הבאות: משתמשים אנונימיים כדי לאפשר לכל המשתמשים לצפות ב-API. משתמשים רשומים כדי לאפשר רק למשתמשים רשומים לצפות ב-API. אם נרשמתם לגרסת הבטא של התכונה 'ניהול קהלים', אתם צריכים לבחור אחת מהאפשרויות הבאות: Public (גלוי לכולם) כדי לאפשר לכל המשתמשים להציג את ה-API. משתמשים מאומתים כדי לאפשר רק למשתמשים רשומים לצפות ב-API. קהלים נבחרים כדי לבחור את הקהלים הספציפיים שרוצים שיוכלו לראות את ה-API. תוכלו לנהל את הרשאות הגישה של הקהל בשלב מאוחר יותר, כמו שמתואר במאמר ניהול החשיפה של API בפורטל.
   תמונה לתצוגה	כדי להציג תמונה בכרטיס ה-API בדף ממשקי ה-API, לוחצים על בחירת תמונה. בתיבת הדו-שיח בחירת תמונה, בוחרים תמונה קיימת, מעלים תמונה חדשה או מציינים את כתובת ה-URL של תמונה חיצונית ולוחצים על בחירה. מציגים בתצוגה מקדימה את התמונה הממוזערת של ה-API ולוחצים על Select. אפשר להוסיף תמונה מאוחר יותר, כמו שמתואר במאמר ניהול התמונה של כרטיס API. כשמציינים תמונה עם כתובת URL חיצונית, התמונה לא תועלה לנכסים שלכם. בנוסף, טעינת התמונה בפורטל המשולב תהיה כפופה לזמינות שלה, וייתכן שהיא תיחסם או תוגבל בהתאם למדיניות אבטחת התוכן.
   קטגוריות	כאן מוסיפים את הקטגוריות שבהן ה-API יתויג כדי לאפשר למפתחי אפליקציות למצוא ממשקי API קשורים בדף ממשקי ה-API. כדי לזהות קטגוריה: בוחרים קטגוריה מהרשימה הנפתחת. כדי להוסיף קטגוריה חדשה, מקלידים את שם הקטגוריה ומקישים על Enter. הקטגוריה החדשה תתווסף לדף 'קטגוריות' ותהיה זמינה כשמוסיפים או עורכים ממשקי API אחרים.

7. לוחצים על שמירה.

ניהול תמונת המצב של המסמך

אחרי שמפרסמים את ה-API, תמיד אפשר ליצור תמונת מצב חדשה של מסמכי OpenAPI או GraphQL כדי לעדכן את מאמרי העזרה של ה-API שמפורסמים בפורטל שלכם.

כדי לנהל את תמונת המצב של המסמך:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.
3. לוחצים בשורה של ה-API שרוצים לערוך.
4. בודקים את הסטטוס של תמונת המצב. אם הוא לא עדכני, תוצג ההודעה הבאה:
5. לוחצים על .
6. מבצעים אחת מהמשימות הבאות:
   • כדי לרענן תמונת מצב של מסמך OpenAPI לא עדכני, לוחצים על רענון תמונת מצב.
   • כדי לשנות את המסמך שישמש ליצירת התיעוד עבור ה-API, בקטע 'תיעוד API' לוחצים על בחירת מסמך ובוחרים את המסמך החדש.
7. לוחצים על שמירה.

העיבוד של מסמכי העזרה של ה-API מהמסמך מתווסף לדף ה-API Reference. הסטטוס של תמונת המצב מתעדכן. עד הנוכחי:

פרסום או ביטול הפרסום של API בפורטל

כדי לפרסם API או לבטל את הפרסום שלו בפורטל:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.
3. לוחצים בשורה של ה-API שרוצים לערוך.
4. לוחצים על .
5. בקטע 'פרטי API', בוחרים או מבטלים את הבחירה באפשרות פורסם (מופיע בקטלוג) כדי לפרסם או לבטל את הפרסום של ה-API בפורטל, בהתאמה.
6. לוחצים על שמירה.

ניהול החשיפה של ממשק API בפורטל

כדי לנהל את הרשאות הגישה של API בפורטל, צריך לאפשר גישה אל:

• ציבורי (גלוי לכולם)
• משתמשים מאומתים
• קהלים שנבחרו (אם נרשמתם לגרסת הבטא של תכונת ניהול הקהלים)

כדי לנהל את הרשאות הגישה לממשק API בפורטל:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.
3. לוחצים בשורה של ה-API שרוצים לערוך.
4. לוחצים על .
5. בקטע 'הרשאות גישה ל-API', בוחרים באחת מהאפשרויות הבאות:

6. בוחרים את ההגדרה של הרשאות הגישה. אם נרשמתם לגרסת הבטא של התכונה 'קהלים', אתם צריכים לבחור באחת מהאפשרויות הבאות:

   • ציבורי (גלוי לכולם) כדי לאפשר לכל המשתמשים לצפות בדף.
   • משתמשים מאומתים כדי לאפשר רק למשתמשים רשומים לצפות בדף.
   • קהלים שנבחרו כדי לבחור את הקהלים הספציפיים שרוצים שיוכלו לראות את הדף. מידע נוסף זמין במאמר ניהול הקהלים בפורטל.
   אם לא, בוחרים באחת מהאפשרויות הבאות:
   • משתמשים אנונימיים כדי לאפשר לכל המשתמשים לצפות בדף.
   • משתמשים רשומים כדי לאפשר רק למשתמשים רשומים לצפות בדף.

7. לוחצים על שליחה.

ניהול של כתובת URL לקריאה חוזרת (callback) ל-API

ניהול של כתובת URL לקריאה חוזרת (callback) עבור API. מידע נוסף זמין במאמר מידע על כתובות URL לקריאה חוזרת (callback).

כדי לנהל את כתובת ה-URL לקריאה חוזרת (callback) עבור API:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.
3. לוחצים בשורה של ה-API שרוצים לערוך.
4. לוחצים על .
5. בקטע 'פרטי API', בוחרים או מבטלים את הבחירה באפשרות פורסם (מופיע בקטלוג) כדי לפרסם או לבטל את הפרסום של ה-API בפורטל, בהתאמה.
6. לוחצים על שמירה.

ניהול התמונה של כרטיס API

אפשר לנהל את התמונה שמופיעה עם כרטיס API בדף ממשקי ה-API על ידי הוספה או שינוי של התמונה הנוכחית.

כדי לנהל את התמונה של כרטיס API:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.
3. לוחצים בשורה של ה-API שרוצים לערוך.
4. לוחצים על .

5. בקטע 'פרטי ה-API':

   • אם לא נבחרה תמונה, לוחצים על בחירת תמונה כדי לציין או להעלות תמונה.
   • לוחצים על שינוי תמונה כדי לציין או להעלות תמונה אחרת.
   • לוחצים על ה-x בתמונה כדי להסיר אותו.

   כשמציינים תמונה, צריך לציין תמונה עם כתובת URL חיצונית של הפריט בקטלוג, או נתיב קובץ של קובצי תמונה ששמורים בפורטל, למשל /files/book-tree.jpg. כשמציינים את כתובת ה-URL של תמונה חיצונית, התמונה לא יועלו לנכסים שלכם. כמו כן, טעינה של התמונה יהיה כפוף לזמינות שלו, וייתכן שהוא ייחסם או יוגבל על ידי מדיניות אבטחת תוכן.

6. לוחצים על שמירה.

תיוג API באמצעות קטגוריות

תיוג API באמצעות קטגוריות באחת מהדרכים הבאות:

• ניהול הקטגוריות שאליהן API מתויג בזמן עריכת ה-API, כפי שמתואר בהמשך.
• ניהול ממשקי ה-API שתויגו בקטגוריה מסוימת בזמן עריכת הקטגוריה.

כדי לתייג API לקטגוריות בזמן עריכת ה-API:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.
3. לוחצים בשורה של ה-API שרוצים לערוך.
4. לוחצים על .
5. לוחצים בתוך השדה קטגוריות ומבצעים אחת מהפעולות הבאות:
   • בוחרים קטגוריה מהרשימה הנפתחת.
   • כדי להוסיף קטגוריה חדשה, מקלידים את שם הקטגוריה ומקישים על Enter. הקטגוריה החדשה תתווסף לדף 'קטגוריות' ותהיה זמינה כשמוסיפים או עורכים ממשקי API אחרים.
6. חוזרים על הפעולה כדי לתייג את ה-API לקטגוריות נוספות.
7. לוחצים על שמירה.

עריכת השם המוצג והתיאור

כדי לערוך את השם המוצג והתיאור:

1. נכנסים לקטלוג ממשקי ה-API.
2. לוחצים על הכרטיסייה APIs אם היא עדיין לא נבחרה.
3. לוחצים בשורה של ה-API שרוצים לערוך.
4. לוחצים על .
5. עורכים את השדות שם לתצוגה ותיאור להצגה לפי הצורך.
6. לוחצים על שמירה.

הסרת API מהפורטל

כדי להסיר ממשק API מהפורטל:

1. נכנסים לקטלוג ממשקי ה-API.
2. בוחרים את ממשקי API, אם עדיין לא נבחרו.
3. מציבים את הסמן מעל ה-API ברשימה כדי להציג את תפריט הפעולות.
4. לוחצים על .

ניהול הקטגוריות שמשמשות למציאת ממשקי API קשורים

לתייג API באמצעות קטגוריות כדי לאפשר למפתחי אפליקציות למצוא ממשקי API קשורים בדף ממשקי ה-API של הפורטל הפעיל. מוסיפים ומנהלים קטגוריות, כפי שמתואר בקטעים הבאים.

הדף 'קטגוריות'

כדי להציג את הדף 'קטגוריות':

1. בוחרים באפשרות פרסום > פורטלים ובוחרים את הפורטל.
2. לוחצים על קטלוג API בדף הבית של הפורטל.

   לחלופין, אפשר לבחור קטלוג API בתפריט הנפתח של הפורטל בסרגל הניווט העליון.

3. לוחצים על הכרטיסייה קטגוריות.

בכרטיסייה 'קטגוריות' בקטלוג ממשקי ה-API מוצגת רשימת הקטגוריות שהוגדרו לפורטל שלכם.

כפי שמודגש באיור הקודם, דף ממשקי ה-API מאפשר לכם:

• הצגת הקטגוריות וממשקי ה-API שאליהם הם תויגו
• להוספת קטגוריה
• עריכת קטגוריה
• מחיקת קטגוריה
• ניהול ממשקי API שפורסמו בפורטל שלך. לעיון בקטלוג ממשקי ה-API

הוספת קטגוריה

מוסיפים קטגוריה באחת מהדרכים הבאות:

• צריך להזין את שם הקטגוריה כשמוסיפים API לפורטל
• מוסיפים קטגוריה באופן ידני כמו שמתואר בהמשך

הקטגוריה החדשה תתווסף לדף 'קטגוריות' ותהיה זמינה כשמוסיפים או עורכים ממשקי API אחרים.

כדי להוסיף קטגוריה באופן ידני:

1. נכנסים לדף 'קטגוריות'.
2. לוחצים על הסימן +.
3. מזינים את השם של הקטגוריה החדשה.
4. (אופציונלי) בוחרים ממשק API אחד או יותר לתיוג הקטגוריה.
5. לוחצים על יצירה.

עריכת קטגוריה

כדי לערוך קטגוריה:

1. נכנסים לדף 'קטגוריות'.
2. לוחצים על .
3. עורכים את שם הקטגוריה.
4. מוסיפים או מסירים תגי API.
5. לוחצים על שמירה.

מחיקת קטגוריה

כשמוחקים קטגוריה, גם כל תגי ה-API של הקטגוריה הזו נמחקים.

כדי למחוק קטגוריה:

1. נכנסים לדף 'קטגוריות'.
2. ממקמים את הסמן מעל הקטגוריה שרוצים לערוך כדי להציג את תפריט הפעולות.
3. לוחצים על .
4. עורכים את שם הקטגוריה.
5. מוסיפים או מסירים ממשקי API.
6. לוחצים על שמירה.

פתרון בעיות בממשקי ה-API שפורסמו

בקטעים הבאים תמצאו מידע שיעזור לכם לפתור שגיאות ספציפיות בממשקי ה-API שפורסמו.

שגיאה: אחזור השגיאה שהוחזרה במהלך השימוש ב-API הזה נכשל

כשמשתמשים ב-API הזה, אם מוחזרת השגיאה TypeError: Failed to fetch, כדאי להביא בחשבון את הסיבות והפתרונות האפשריים הבאים:

• במקרה של שגיאות של תוכן מעורב, השגיאה עשויה לנבוע מבעיה ידועה בממשק המשתמש של swagger-ui. אחת מהדרכים לעקוף את הבעיה היא להקפיד לציין HTTPS לפני HTTP בהגדרה של schemes במסמך OpenAPI. לדוגמה:

  schemes:
     - https
     - http
  

• במקרה של שגיאות שקשורות להגבלה של שיתוף משאבים בין מקורות (CORS), צריך לוודא ששרתי ה-proxy ל-API נתמכים ב-CORS. CORS הוא מנגנון סטנדרטי שמאפשר בקשות ממקורות שונים בצד הלקוח. מידע נוסף זמין בקטע הגדרת שרת proxy ל-API כך שיתמוך ב'התנסות עם ה-API הזה'.

שגיאה: 'Access-Control-Allow-Origin' הכותרת מכילה מספר ערכים '*, *', אבל מותר להשתמש רק באחד

במהלך השימוש ב-API הזה, יכול להיות שתתקבל הודעת השגיאה הבאה אם הכותרת Access-Control-Allow-Origin כבר קיימת:

The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed.

כדי לתקן את השגיאה הזו, צריך לשנות את המדיניות של AssignMessage כך שתשתמש ב-<Set> כדי להגדיר את כותרות ה-CORS במקום <Add>, כפי שמוצג בקטע שלמטה. למידע נוסף, אפשר לקרוא את המאמר הרלוונטי בקהילה.

<AssignMessage async="false" continueOnError="false" enabled="true" name="add-cors">
    <DisplayName>Add CORS</DisplayName>
    <FaultRules/>
    <Properties/>
    <Set>
        <Headers>
            <Header name="Access-Control-Allow-Origin">{request.header.origin}</Header>
            <Header name="Access-Control-Allow-Headers">origin, x-requested-with, accept, content-type, authorization</Header>
            <Header name="Access-Control-Max-Age">3628800</Header>
            <Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

שגיאה: אסור להשתמש בשדה כותרת הבקשה

כשמשתמשים ב-API הזה כדי לנסות את ה-API, אם מקבלים שגיאת Request header field not allowed, בדומה לדוגמה שלמטה, יכול להיות שתצטרכו לעדכן את הכותרות שנתמכות במדיניות CORS. לדוגמה:

Access to XMLHttpRequest ... has been blocked by CORS policy: Request header field
content-type is not allowed by Access-Control-Allow-Headers in preflight response

בדוגמה הזו, צריך להוסיף את הכותרת content-type לקטע Access-Control-Allow-Headers במדיניות CORS assignMessage, כפי שמתואר צירוף של מדיניות CORS לשרת API חדש.

שגיאה: הגישה נדחתה במהלך קריאה לשרת proxy ל-API באמצעות OAuth2

מדיניות OAuthV2 של Apigee מחזירה תגובת אסימון שמכילה מאפיינים מסוימים שלא תואמים ל-RFC. לדוגמה, המדיניות תחזיר אסימון עם הערך BearerToken, במקום הערך הצפוי שתואם ל-RFC Bearer. התשובה הלא תקינה הזו של token_type יכולה לגרום לשגיאת Access denied כשמשתמשים ב-API הזה.

כדי לפתור את הבעיה, ניתן ליצור מדיניות JavaScript או AssignMessage כדי להפוך את פלט המדיניות לפורמט תואם. מידע נוסף זמין במאמר הבא: התנהגות שלא תואמת ל-RFC.