← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

🧰 REST API vs HTTP API — lesson 02

⏮️ Before HTTP APIs (2019)

REST APIs were the only choice: powerful but priced and configured for every feature, even when a service only needed to forward to Lambda.

✅ फायदे

  • REST: API keys + usage plans, caching, request validation, mapping templates, WAF, private endpoints
  • HTTP: cheaper (~$1.00 vs ~$3.50 per million), faster, built-in JWT authorizers and simple CORS

❌ तोटे

  • REST costs more and has more knobs to get wrong
  • HTTP lacks caching, usage plans, request validation and WAF integration

👍 वापरा जेव्हा

  • REST: public APIs with partners, keys and quotas, or when you need caching/WAF
  • HTTP: Lambda or HTTP back ends behind JWT auth

👎 दोनदा विचार करा जेव्हा

  • REST for a simple internal proxy
  • HTTP when you later discover you need usage plans

🛎️ API Gateway vs an Application Load Balancer — lesson 01

⏮️ Before managed gateways

Each service ran its own nginx with hand-written auth, rate limits and logging.

✅ फायदे

  • gateway: auth, throttling, keys, caching, per-request pricing, zero servers
  • ALB: per-hour pricing that wins at steady high volume, long connections, no 29 s limit

❌ तोटे

  • gateway: per-request cost grows with traffic; 29 s integration timeout; 10 MB payloads
  • ALB: you build auth (or OIDC on the listener), throttling and keys yourself

👍 वापरा जेव्हा

  • gateway: public APIs, serverless back ends, partner access
  • ALB: high steady traffic to containers, long requests, gRPC

👎 दोनदा विचार करा जेव्हा

  • billions of internal calls through API Gateway
  • an ALB exposed to partners with no rate limits

🔐 IAM vs JWT vs Lambda authorizers — lesson 06

⏮️ Before authorizers

Every back end parsed and checked tokens itself — some forgot the expiry.

✅ फायदे

  • IAM (SigV4): callers inside AWS, no secrets to share
  • JWT: Cognito or any OIDC issuer — checked by the gateway, no code
  • Lambda authorizer: any rule you can code, result cached

❌ तोटे

  • IAM: awkward for browsers and mobile apps
  • JWT: only what's in the token
  • Lambda: your code, your bugs, extra latency on cache misses

👍 वापरा जेव्हा

  • service-to-service in AWS: IAM
  • users of web/mobile apps: JWT
  • legacy tokens or special rules: Lambda

👎 दोनदा विचार करा जेव्हा

  • a Lambda authorizer that re-implements JWT checks badly
  • caching an authorizer answer across users with a shared key

🔑 API keys vs authentication — lessons 06, 07

⏮️ Before usage plans

Anyone who knew the URL could call the API as often as they liked.

✅ फायदे

  • API keys identify a client for usage plans, quotas and per-client throttling
  • easy to hand to a partner

❌ तोटे

  • a key is a shared string: it leaks in apps, logs and screenshots
  • it proves which client, not which person

👍 वापरा जेव्हा

  • metering and limiting partners
  • always together with real auth (IAM, JWT, Lambda authorizer)

👎 दोनदा विचार करा जेव्हा

  • an API key as the only protection
  • putting the key inside a mobile app and calling it secure

📌 Gateway cache vs CloudFront vs an app cache — lesson 08

⏮️ Before caching

Every identical request hit the back end and the database.

✅ फायदे

  • gateway cache: per stage, per method, TTL 0–3600 s (default 300)
  • CloudFront: global edge cache, cheaper per GB
  • app cache (Redis): shared across every entry point

❌ तोटे

  • gateway cache is billed per hour by size, even when idle
  • CloudFront needs cache keys designed carefully
  • app cache is code to write and run

👍 वापरा जेव्हा

  • gateway cache for hot read-only GETs on REST APIs
  • CloudFront for public content
  • app cache for data many services share

👎 दोनदा विचार करा जेव्हा

  • caching per-user answers under a shared key
  • turning on a cache for write-heavy routes

🗺️ Proxy integration vs mapped integration — lessons 03, 04

⏮️ Before proxy integrations

Every route needed a mapping template to reshape requests and responses.

✅ फायदे

  • proxy: the whole request goes to the back end as-is — one route, no templates
  • mapped: the office reshapes input and output — the back end stays simple

❌ तोटे

  • proxy: the back end must build the full HTTP response itself
  • mapped: templates (VTL) are hard to test and easy to break

👍 वापरा जेव्हा

  • proxy: Lambda and HTTP back ends you own
  • mapped: calling AWS services directly, legacy back ends

👎 दोनदा विचार करा जेव्हा

  • huge VTL templates holding business logic
  • {proxy+} routes that expose admin paths by accident