API گیٹ وے پیٹرن اور جدید ایپلی کیشنز کے لیے بہترین طرز عمل

API گیٹ وے تمام انٹرپرائز ٹریفک کا اوسطاً 83% ہینڈل کرتے ہیں، جو کلائنٹ ایپلیکیشنز کے لیے سنگل انٹری پوائنٹ کے طور پر کام کرتے ہیں۔ ایک اچھی طرح سے ڈیزائن کیا گیا API گیٹ وے کلائنٹ-سرور مواصلات کو آسان بناتا ہے، سیکیورٹی پالیسیوں کو نافذ کرتا ہے، اور تمام سروسز پر مشاہدہ فراہم کرتا ہے۔ ایک ناقص ڈیزائن ایک رکاوٹ اور ناکامی کا واحد نقطہ بن جاتا ہے۔

یہ گائیڈ API گیٹ وے فن تعمیر کے نمونوں، ٹیکنالوجی کے انتخاب، اور ویب ایپلیکیشنز، ERP سسٹمز، اور ای کامرس پلیٹ فارمز کے لیے بہترین طریقوں پر عمل درآمد کا احاطہ کرتا ہے۔

اہم ٹیک ویز

• API گیٹ ویز تمام سروسز میں نقل کو ختم کرنے کے لیے کراس کٹنگ خدشات (تصویر، شرح محدود، لاگنگ) کو مرکزی بناتے ہیں۔
• گیٹ وے کی سطح پر شرح کو محدود کرنا بیک اینڈ سروسز کو ٹریفک میں اضافے اور غلط استعمال سے بچاتا ہے۔
• سرکٹ بریکر پیٹرن جھرن کی ناکامیوں کو روکتے ہیں جب ڈاؤن اسٹریم سروسز غیر صحت مند ہوں۔
• گیٹ وے کے ذریعے API ورژن بنانا آپ کی API سطح کے پسماندہ مطابقت پذیر ارتقا کو قابل بناتا ہے۔

---

بنیادی گیٹ وے پیٹرنز

پیٹرن 1: روٹنگ کی درخواست کریں۔

گیٹ وے روٹس یو آر ایل پاتھ، ہیڈرز، یا درخواست کی دیگر خصوصیات کی بنیاد پر مناسب بیک اینڈ سروس کی درخواست کرتا ہے۔

# Nginx as API gateway
upstream api_service {
    server api-1:3001;
    server api-2:3001;
}

upstream auth_service {
    server auth:9000;
}

upstream web_service {
    server web:3000;
}

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

    location /api/v1/ {
        proxy_pass http://api_service;
    }

    location /auth/ {
        proxy_pass http://auth_service;
    }

    location / {
        proxy_pass http://web_service;
    }
}

پیٹرن 2: تصدیق اور اجازت

ہر سروس میں اسے لاگو کرنے سے بچنے کے لیے گیٹ وے پر توثیق کو مرکزی بنائیں۔

// NestJS middleware for JWT validation at the gateway level
@Injectable()
export class GatewayAuthMiddleware implements NestMiddleware {
  constructor(private readonly jwtService: JwtService) {}

  async use(req: Request, res: Response, next: NextFunction) {
    // Skip public endpoints
    if (this.isPublicEndpoint(req.path)) {
      return next();
    }

    const token = this.extractToken(req);
    if (!token) {
      throw new UnauthorizedException('Missing authentication token');
    }

    try {
      const payload = await this.jwtService.verifyAsync(token);
      req['user'] = payload;
      next();
    } catch {
      throw new UnauthorizedException('Invalid token');
    }
  }

  private extractToken(req: Request): string | undefined {
    // Check cookie first, then Authorization header
    return req.cookies?.ecosire_auth
      || req.headers.authorization?.replace('Bearer ', '');
  }

  private isPublicEndpoint(path: string): boolean {
    const publicPaths = ['/health', '/api/v1/products', '/api/v1/blog'];
    return publicPaths.some(p => path.startsWith(p));
  }
}

پیٹرن 3: شرح کی حد

// Rate limiting configuration per endpoint type
const rateLimits = {
  public: { windowMs: 60000, max: 100 },     // 100 req/min for public APIs
  authenticated: { windowMs: 60000, max: 500 }, // 500 req/min for authenticated users
  admin: { windowMs: 60000, max: 1000 },       // 1000 req/min for admin
  webhooks: { windowMs: 60000, max: 50 },       // 50 req/min for webhooks
};

پیٹرن 4: سرکٹ بریکر

جب ڈاؤن اسٹریم سروس ناکام ہوجاتی ہے، تو سرکٹ بریکر جھرن کی ناکامیوں کو روکتا ہے:

[Closed] --> (failures exceed threshold) --> [Open] --> (timeout expires) --> [Half-Open]
    ^                                                                            |
    |                                        (success)                           |
    +--------------------------------------------------------------------<-------+
    |                                        (failure)                           |
    |                                           +-------->  [Open]

ریاستیں:

• بند: درخواستیں عام طور پر گزرتی ہیں۔ ناکامی کی گنتی کو ٹریک کریں۔
• کھلا: تمام درخواستیں سروس کو کال کیے بغیر فوری طور پر ناکام ہوجاتی ہیں۔ کیشڈ/فال بیک جواب واپس کریں۔
• آدھا کھلا: ایک درخواست کے ذریعے اجازت دیں۔ اگر یہ کامیاب ہوجاتا ہے تو، سرکٹ کو بند کردیں. اگر یہ ناکام ہو جائے تو دوبارہ کھولیں۔

پیٹرن 5: رسپانس کیشنگ

# Cache GET responses for public endpoints
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=60m;

location /api/v1/products {
    proxy_pass http://api_service;
    proxy_cache api_cache;
    proxy_cache_valid 200 5m;
    proxy_cache_valid 404 1m;
    proxy_cache_key "$scheme$request_method$host$request_uri";
    add_header X-Cache-Status $upstream_cache_status;
}

---

API ورژن بنانے کی حکمت عملی

تجویز: URL پاتھ ورژننگ۔ یہ سب سے واضح، سب سے زیادہ ڈیبگ ایبل، اور گیٹ وے کی سطح پر روٹ کرنے کے لیے سب سے آسان ہے۔

بریکنگ بمقابلہ نان بریکنگ تبدیلیاں

---

گیٹ وے ٹیکنالوجی کا موازنہ

زیادہ تر SMBs کے لیے: Nginx کافی ہے۔ یہ سب ملی سیکنڈ اوور ہیڈ کے ساتھ روٹنگ، SSL ختم کرنے، شرح کو محدود کرنے، اور کیشنگ کو ہینڈل کرتا ہے۔ جب آپ کو اعلی درجے کی پلگ ان صلاحیتوں کی ضرورت ہو تو کانگ میں اپ گریڈ کریں (OAuth2، تبدیلی کی درخواست، تجزیات)۔

---

گیٹ وے پر مشاہدہ

لاگنگ کی درخواست کریں۔

log_format gateway '$remote_addr - $remote_user [$time_local] '
                   '"$request" $status $body_bytes_sent '
                   '"$http_referer" "$http_user_agent" '
                   '$request_time $upstream_response_time '
                   '$http_x_request_id';

access_log /var/log/nginx/gateway.log gateway;

میٹرکس کا مجموعہ

گیٹ وے کی سطح پر ان میٹرکس کو ٹریک کریں:

• درخواست کی شرح بذریعہ اختتامی نقطہ، طریقہ، اور اسٹیٹس کوڈ
• لیٹنسی ڈسٹری بیوشن (P50, P95, P99) بذریعہ اختتامی نقطہ
• اختتامی نقطہ اور غلطی کی قسم کے لحاظ سے خرابی کی شرح
• کلائنٹ کے ذریعہ ریٹ کی حد ہٹ
• کیشے ہٹ کا تناسب اختتامی نقطہ کے لحاظ سے
• اپ اسٹریم رسپانس ٹائم بمقابلہ کل رسپانس ٹائم

---

گیٹ وے پر ہینڈلنگ میں خرابی۔

مستقل خرابی کے جوابات

گیٹ وے کو مختلف پسدید خدمات سے غلطی کے جوابات کو معمول پر لانا چاہیے:

{
  "error": {
    "code": "SERVICE_UNAVAILABLE",
    "message": "The requested service is temporarily unavailable",
    "requestId": "req_abc123",
    "timestamp": "2026-03-16T14:32:01Z"
  }
}

دوبارہ کوشش کریں اور ٹائم آؤٹ کنفیگریشن

location /api/ {
    proxy_pass http://api_service;

    # Timeout configuration
    proxy_connect_timeout 5s;
    proxy_send_timeout 30s;
    proxy_read_timeout 30s;

    # Retry on connection errors only (not on 5xx)
    proxy_next_upstream error timeout;
    proxy_next_upstream_tries 2;

    # Custom error pages
    error_page 502 503 504 /api-error.json;
}

مکرم انحطاط

جب ایک غیر اہم بیک اینڈ سروس بند ہوتی ہے، تو گیٹ وے غلطیاں واپس کرنے کے بجائے کیشڈ جوابات یا فال بیک ڈیٹا پیش کر سکتا ہے:

---

گیٹ وے سیکیورٹی پیٹرنز

توثیق کی درخواست کریں۔

بیک اینڈ سروسز کو آگے بھیجنے سے پہلے درخواست کے ڈھانچے کی توثیق کریں:

• نامعلوم مواد کی اقسام کے ساتھ درخواستوں کو مسترد کریں۔
• فی اختتامی نقطہ پر جسم کے سائز کی زیادہ سے زیادہ درخواست کو نافذ کریں۔
• مطلوبہ ہیڈر کی توثیق کریں (API ورژن، مواد کی قسم)
• مشکوک ہیڈر (ہاپ بائی ہاپ ہیڈرز، سرور اندرونی ہیڈر) کو ہٹا دیں

ایڈمن اینڈ پوائنٹس کے لیے IP کی اجازت دینا

location /api/admin/ {
    allow 203.0.113.0/24;  # Office IP range
    allow 10.0.0.0/8;      # Internal network
    deny all;

    proxy_pass http://api_service;
}

تبدیلی کی درخواست کریں۔

گیٹ وے آگے بھیجنے سے پہلے ہیڈر کو شامل، ترمیم یا ہٹا سکتا ہے:

location /api/ {
    proxy_pass http://api_service;

    # Add security headers
    proxy_set_header X-Request-ID $request_id;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;

    # Remove internal headers from responses
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
}

---

اکثر پوچھے گئے سوالات

کیا ہمیں یک سنگی ایپلیکیشن کے لیے API گیٹ وے کی ضرورت ہے؟

ہاں، لیکن ایک آسان۔ یہاں تک کہ یک سنگی کے لیے، Nginx ایک ریورس پراکسی کے طور پر SSL کو ختم کرنے، شرح کو محدود کرنے، جامد فائل کی خدمت، اور سیکیورٹی ہیڈر فراہم کرتا ہے۔ آپ کو یک سنگی کے لیے کانگ یا AWS API گیٹ وے کی ضرورت نہیں ہے، لیکن آپ کو انٹرنیٹ اور اپنے ایپلیکیشن سرور کے درمیان کسی چیز کی ضرورت ہے۔

ہم API گیٹ وے فیل اوور کو کیسے ہینڈل کرتے ہیں؟

کلاؤڈ لوڈ بیلنسر (AWS ALB، Cloudflare) کے پیچھے متعدد گیٹ وے مثالیں چلائیں۔ اگر ایک گیٹ وے مثال ناکام ہو جاتی ہے تو، لوڈ بیلنسر ٹریفک کو صحت مند مثالوں کی طرف لے جاتا ہے۔ Nginx کے لیے، فعال صحت کی جانچ اور غیر صحت مند اپ اسٹریم کو خودکار طریقے سے ہٹانے کا استعمال کریں۔

کیا API گیٹ وے کو توثیق کو ہینڈل کرنا چاہئے یا ہر سروس کو چاہئے؟

گیٹ وے کو توثیق کو ہینڈل کرنا چاہئے (ٹوکن کی تصدیق کرنا درست ہے)۔ انفرادی خدمات کو اجازت کو ہینڈل کرنا چاہئے (یہ جانچنا کہ آیا تصدیق شدہ صارف کو مخصوص کارروائی کی اجازت ہے)۔ یہ علیحدگی گیٹ وے کو ہلکا رکھتی ہے اور خدمات کو رسائی کنٹرول کے عمدہ فیصلے کرنے کی اجازت دیتی ہے۔

ہم API گیٹ وے پر CORS کو کیسے ہینڈل کرتے ہیں؟

CORS کو گیٹ وے کی سطح پر کنفیگر کریں تاکہ تمام سروسز میں CORS ہیڈرز کی نقل نہ بن سکے۔ Access-Control-Allow-Origin کو اپنے مخصوص فرنٹ اینڈ ڈومینز پر سیٹ کریں (کبھی بھی اسناد کے ساتھ پروڈکشن میں * استعمال نہ کریں)۔ بیک اینڈ سروسز پر بوجھ کم کرنے کے لیے گیٹ وے پر پری فلائٹ آپشنز کی درخواستوں کو ہینڈل کریں۔

---

آگے کیا آتا ہے۔

API گیٹ وے آپ کے انفراسٹرکچر کا سامنے کا دروازہ ہے۔ مرئیت کے لیے اسے مانیٹرنگ، تحفظ کے لیے سیکیورٹی سختی، اور صلاحیت کی منصوبہ بندی کے لیے لوڈ ٹیسٹنگ کے ساتھ جوڑیں۔

API آرکیٹیکچر مشاورت کے لیے ECOSIRE سے رابطہ کریں، یا مکمل انفراسٹرکچر روڈ میپ کے لیے ہماری DevOps گائیڈ کو دریافت کریں۔

---

ECOSIRE کے ذریعہ شائع کیا گیا -- کاروباروں کو توسیع پذیر API انفراسٹرکچر بنانے میں مدد کرنا۔