API Gateway

Fully managed service to create, publish, maintain, monitor, and secure APIs at any scale

Create APIs that act as a front door for applications to access data, business logic, or functionality from back-end services

API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent APl calls, including traffic management, authorization, and monitoring.

Allows you to track and control any usage of the API. Throttle requests to help prevent attacks.
Highly scalable (happens automatically) and cost effective
Exposes HTTPS endpoints to define a REST API
Send each API endpoint to a different target
Maintains Multiple Versions of your API

Configuration

Resources When you create an APl you need to also create multiple Resources. Resources are the urls you define eg. /projects Resources can have child resources eg. /projects/-id-/edit

Methods You need to define Methods on Resources You can define multiple Methods on a Resource Methods allow you to make APl calls that resource url with that protocol eg. GET /projects/-id- POST /projects/-id-

Stages In order to use your APl you need to Deploy it to Stages Stages are versions of your API

Invoke URL For each stage AWS provides you a Invoke URL This is where you’ll make your API calls. | It is possible to use a custom domain for your Invoke URL

Deploy API Every-time you make a change to your APl you need to Deploy it via the Deploy API action. When you deploy you choose the stage

When you create an API Method on a resource you need to choose the Integration type.

The most common Integration type is Lambda

Caching

API Caching can be enabled to cache your endpoints response to API calls

When enabled on a stage, APIGW caches responses from your endpoint with specified TTL period
APIGW responds to requests by looking up the response from the cache (instead of making a request to the endpoint)

✅ Reduces the number of calls made to your endpoint ✅ Improves latency

CORS

CORS is a way that the server at the other end (not the code in the browser) can relax a same-origin policy

Same Origin Policy

Sam Origin Policy is a concept in the application security model, where a web browser permits scripts contained in a first web page to access data in a second website

Same Origin Policies are used to help prevent Cross-Site Scripting (XSS) attacks.
They only works if both web pages have the same origin
They are enforced at the web browser level
They ignore tools such as Postman or Curl