שער API וניתוב

1) תפקיד שער API בארכיטקטורה

• מקבל תנועה נכנסת (HTTP/HTTP2/HTTP3, שקע רשת, gRPC)
• מסלולים לפי כללים (מארח/נתיב/כותרות/שיטה/שאילתה/גאו/משקל/בריאות);
• מיישם מדיניות מקצה לקצה: אימות/אישור, הגבלת קצב, WAF, CORS, מטמון;
• מבצע טרנספורמציות (נורמליזציה של כותרות/גופים, gRPC↔JSON, תפירת GraphQL);
• מספק יציבות (פסקי זמן, תיקונים, מפסק חשמלי, זיהוי חריג);
• נותן יכולת תצפית וחיוב (יומנים, מדדים, עקבות, מכסות);
• מבודד את הטופולוגיה הפנימית (שירות רשת, שירותים פרטיים).

לעתים קרובות משתמשים בזוגות: Edge/API-Gateway + Ingress/Mesh (שליח/איסטיו/לינקרד) - הראשון מחליט על מדיניות חוץ, השנייה - מזרח-מערב.

2) טופולוגיות טיפוסיות

שער גלובלי יחיד (CDN/edge POP = L7 gateway # services) - מדיניות פשוטה ומרכזית.
שערים אזוריים (לכל אזור) + ניתוב geo/latency חכם.
מסלולים ייעודיים/תת-דומים/מפתחות, מכסות ומגבלות לדייר.
היברידי: על ענן prem +, קישור פרטי/מציץ, גיבוי פרטי מאחורי שער API.

3) כללי ניתוב L7

• מארח/שביל: "Api. דוגמא. com 'ac '/v1/הזמנות/'.
• כותרות: ”X-Client”, ”X-Region”, ”User-Agent”, ”קבל”.
• שיטה/תוכן-סוג: הבחנה בין JSON/Proto/GraphQL.
• שאילתה/שבר: זהיר - משפיע על מטמון/וריאנטים.
• Geo/Latency: POP/Area הקרוב ביותר, כשל תחת השפלה.
• משוקלל/כנרי: התפלגות תנועה 90/10, 50/50, דביק על ידי עוגייה.
• זיקה: חשיש מבוסס על מפתח/אסימון (זהירות בעת סקיילינג).

yaml nginx. ingress. kubernetes. io/canary: "true"
nginx. ingress. kubernetes. io/canary-weight: "10" # 10% traffic to new backend

yaml match: { prefix: "/orders", headers: [{name: "X-Experiment", exact_match: "new"}] }
route: { cluster: orders-v2 }

4) פרוטוקולים ותאימות

REST/JSON - ברירת מחדל, מתאר OpenAPI עבור אימות לקוח/דור.
GRPC - פרוטו בינארי מעל HTTP/2; ללקוחות חיצוניים, השתמשו בטרנספורמציה של GRPC-JSON.
שירותי GraphQL - Aggregates; על המתחם, לפקח המורכבות/עומק של שאילתות.
שקע אינטרנט/SSE - דו כיווני/דחף; שקול דביק ופסקי זמן.
HTTP/2/3 (QUIC) - ריבוי/התחלה מהירה; ודא תאימות WAF/proxy.

5) אבטחה: אימות ואישור

5. 1 טרנספורמציה

TLS 1. 2 + בהיקף, HSTS, הידוק OCSP, PFS.
MTLS עבור API B2B/internal ומכונה למכונה.
IP allowlist/denylist, גיאו-אילוצים.

5. 2 שכבת יישום

OAuth2/OIDC: אסימוני נושא JWT, חתימה/תפוגה/אימות קהל.
NMAS/signatures: date + canonized line + signal (AWS-like) - הגנה מפני החלפה, חזרה (nunce/time window).
מפתחות API: כמזוהה בלבד; זכויות - באמצעות RBAC/ABAC/סקופים.
מקור ברור, מטמון טרום טיסה.
חתימות (OWASP API Top 10), אנומליה, הגנה בוט, שדות JSON רקורסיבי.
DDOS/Ablusion: מגביל חיבור, דלי טוקן/ליקי, צפור + מהירות ממוצעת, חרם דינמי.

yaml plugins:
- name: oidc config: { issuer: "...", client_id: "...", client_secret: "...", scopes: ["orders. read"] }
- name: rate-limiting config: { minute: 600, policy: local }

6) אימות, שינוי ותאימות

סכימות: אימות גוף/כותרות/פרמטרים לפי OpenAPI/JSON-Schema/Protobuf.
טרנספורמציות: נורמליזציה שדה, מיסוך PII, תוספת של כותרות קורלציה ('טרקפרנט', 'x-בקשה-id').
Versioning: ”כותרת: X-API-Version”, prefixes '/v1 ', versioning-משאבים; מדיניות הפוגה שקיעה.
אחורנית: הוספת שדה בלבד; הימנע מ ”שבירת” שינויים ללא גרסה חדשה.
Idempotency: 'Idempotency-Key' it sitePOST; שער מאחסן מפתחות ברדיס עם טי-טי-אל.

7) עמידות: מדיניות חיבור

פסקי זמן: חיבור/קריאה/כתיבה; ברירות מחדל סבירות (לדוגמה: 1/5-s/5).
חזרות: רק עבור בטוח ואידימפוטנטי; ג 'יטר, גיבוי מעריכי, ניסיונות מקסימליים.
מפסק מעגל: פתוח על שגיאות/latency; חצי פתוח לדגימות.
זיהוי חריג יותר - להסיר מקרים רעים מהבריכה.
מחיצה/תחרות: מגבלות על בקשות לכל מסלול.
כשל: אקטיבי/פסיבי, השפלה איזורית.
תנועת צל: V2 ”אפור” לרוץ במקביל V1 (אין השפעה על תגובה) לשם השוואה.

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 1024 max_pending_requests: 2048 max_retries: 3

8) מטמון וביצועים

HTTP-culey: "Cache-Control', 'ETag/If-None-Match', 'Vary', 'מעופש-בזמן-לבטל'.
מטמונים/פופ: CDNs עבור API סטטי ומטמון (idempotent Gets).
דחיסה: ”gzip/br” (לא לדחוס כבר דחוס).
בקשה מתמוטטת (”פחם”): שילוב בקשות מקבילות זהות.
עיצוב תגובה: שדות/מסננים, מבוססי סמן, גבולות גודל.

9) יכולת תצפית ותפעול

* latency _ ms p50, p95, p99, "upstream _ images", "retry _ count'," cb _ state "," 429 _ rate "," quate _ usage "terant'.
יומנים: מבניים, עם ”trace _ id/span _ id',” user _ id/terenant _ id', ”client _ ip”.
עקבות: הקשר W3C ("tracepart'," tracestate "), מתפשט במעלה הזרם.
ביקורת: מי גרם למה, עם אילו זכויות; חנויות בלתי ניתנות לשינוי עבור אפליקציות רגישות.
SLO/SLA: יעד p99, תקציב שגיאה; רמת השורש טובה יותר מזו הגלובלית.

10) ניהול תוכניות קיבולת

מכסה לדייר/מפתח/מאגר לקוחות, תוך שעה/שעה/יום.
ברסט + מגבלות ממושכות; דלי דולף להחליק.
הגינות: כאשר עומס יתר - תור הוגן במקום ”נתקל ראשון”.
סדרי עדיפויות: מערכת/מסלולים קריטיים עם עדיפות ובריכות ייעודיות.

11) שינוי ניהול ושחרור

קנרית/כחול-ירוק: ניתוב משקל; התקדמות אוטומטית על SLO (שגיאות/latency).
הצגת שערים/דגלים אחוריים: אפשר על ידי כותרת/אסימון.
אימות צללים/diff: השוואה של גופים/סטטוסים, סובלנות דלתא.
היערכות: מוקצה תחום/נתיבים ('היערכות. אפי... '), מפתחות אישיים ומכסות.

12) דוגמאות הגדרות

12. 1 NGINX - מגבלה בסיסית ושער מטמון

nginx map $http_x_request_id $reqid { default $request_id; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
listen 443 ssl http2;
server_name api. example. com;

security add_header Strict-Transport-Security "max-age = 31536000" always;

location /v1/ {
limit_req zone=perip burst=30 nodelay;
proxy_set_header X-Request-ID $reqid;
proxy_set_header Authorization $http_authorization;
proxy_connect_timeout 1s;
proxy_read_timeout 5s;

proxy_cache api_cache;
proxy_cache_valid 200 10s;
proxy_cache_use_stale error timeout updating;
proxy_pass http://orders-v1;
}
}

12. 2 שליח - איזון וניתוב מחדש

yaml routes:
- match: { prefix: "/orders" }
route:
weighted_clusters:
clusters:
- name: orders-v1 weight: 90
- name: orders-v2 weight: 10 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 2s

12. 3 טראפיק - תוכנות בינוניות וכותרות

yaml http:
middlewares:
secHeaders:
headers:
stsSeconds: 31536000 contentTypeNosniff: true routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: svc-orders middlewares: ["secHeaders"]

13) אנטי דפוסים

מגבלה גלובלית אחת על כל ה ”שכנים הטובים” סובלת מ ”רעש”.
מגשים מחדש ללא אידמפוטנטיות * שכפול אפקטים (תשלומים, יצירת ישויות).
התעלמות מ ”פסק זמן ”/” גודל גוף מקסימלי” = תולים/מתישים עובדים.
ערבוב מדיניות קצה ולוגיקה עסקית בשער (שקילת ההיקף).
חוסר אימות של מזימות ”שבריריות” של לקוחות ו ”שבירה” משחררת.
שקע אינטרנט עירום לא כולל auth/גבולות/זמן סרק.
סודות בכותרות ללא סיבוב; אין mTLS B2Bs פנימיים.

14) ספרי משחק (ימי משחק)

סערת בקשות: לבדוק מגביל/מכסה, 429-התנהגות, השפלה.
אובדן אשכול אחד: חלוקה מחדש של כשל/משקל; קנריות SLO.
תשובות משוקללות: מקסימום גוף/פסק זמן; חיתוך מפרקים.
זריקות/חריגות: כללי WAF, עכבות JSON רקורסיביות, עמקי GRAPHQL גדולים.
עקבות נכשלו לבדוק ”עקבות” התפשטות ודגימה.
סודות: סיבוב מפתח/JWKS, תפוגה סמלית, סובלנות שעון רזה.

15) רשימת מימושים

[ ] Domains/Pats/grasses, OpenAPI/Proto פורסם.

[ ] TLS/mTLS, HSTS, ניהול סודי וסבב מוגדרים.

[ אימות ] (OIDC/HMAC), RBAC/scopes, CORS מאופשר.

[ גבולות ]/מכסות לדייר, תורים הוגנים, 429-UX.

[ ] ניתוב משקל/כותרת, תוכנית כנרית וגלגול חוזר.

[ ] הזמן/החזרה/שובר מעגל/מדיניות חיצונית.

[ אימות ], שינויים, מיסוך מח "ש.

[ ] Edge-culieve/ETag, התמזגות, gzip/br.

[ ] תצפית: מדדים, בולי עץ, מסלולים, לוחות מחוונים והתראות.

[ ] ספרי ריצה: תקריות, סיבוב מפתח, רשימות בלוקים, יום שישי השחור.

16) FAQ

קיו: במה שונה שער ה ־ API מרשת השירות? ‏

א ': שער - צפון-דרום (היקף חיצוני, מדיניות מקצה לקצה). MSH - מזרח-מערב (קישוריות תוך-צרכנית/MTLS/retrai). לעיתים קרובות משמש יחד.

Q: היכן ליישם auth: בשער או בשירותים?
א. שתי הרמות: שער - גרגיר גס (אימות, זכויות בסיסיות/מכסות), שירות - גרגירים עדינים (תפקידי תחום/תכונות).

Q: מתי דרושה התמרת GRPC-JSON?
A: כאשר gRPC פנימי, ומחוץ לו דורש REST/JSON ולקוחות/דפדפנים פשוטים.

קיו: כיצד לבחור אסטרטגיית ורסינינג? ‏

א. עבור API ציבורי - נתיב '/vN '+ כותרות חסך וחפיפה ארוכה. עבור תוכנת יכולת-דגלים/תאימות פנימית.

17) סיכומים

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