Ứng dụng di động và đối tác cần một endpoint chung để gọi vào hệ thống; endpoint đó cũng là nơi xác thực, phân quyền và throttle request trước khi request tới backend integration.

Ứng dụng mobile, đối tác bán hàng và trang quản trị đều gọi tới api.mftech.vn. API Gateway thực hiện một chuỗi bước kiểm tra trước khi request tới mã ứng dụng. Chọn tình huống và gửi request:

Một số yêu cầu khác:

• Chat giữa người mua và người bán cần kết nối hai chiều, backend chủ động đẩy tin nhắn tới client: WebSocket API. Với REST API, mỗi request độc lập và không duy trì kết nối.
• Shipper gửi vị trí liên tục để theo dõi đơn hàng (tình huống “Shipper gửi vị trí liên tục” trong mô phỏng): REST API dùng AWS service integration gọi thẳng PutRecord của Kinesis Data Streams, không cần Lambda trung gian, để Amazon Managed Service for Apache Flink (tên cũ: Amazon Kinesis Data Analytics) phân tích stream. Lambda chỉ xử lý từng request, không phải nơi lưu trữ hay phân tích dữ liệu.
• Tiếp nhận giao dịch từ ứng dụng, kiểm tra dữ liệu đơn giản rồi xử lý, với chi phí vận hành thấp nhất: REST API + Lambda kiểm tra dữ liệu, backend serverless phía sau. Không có máy chủ hay container nào cần vá lỗi.

Xác thực người dùng ở API Gateway có nhiều cơ chế. Ứng dụng mobile mới của MFTECH đăng nhập qua một identity provider bên ngoài tuân thủ OIDC; backend cần kiểm tra JWT và scope với độ trễ, chi phí thấp, không viết mã xác thực. HTTP API với JWT authorizer đáp ứng yêu cầu này: API Gateway kiểm tra chữ ký token bằng public key lấy từ jwks_uri của issuer, kiểm tra các claim iss, aud, exp và yêu cầu token có ít nhất một scope của route; các claim hợp lệ được chuyển tới backend. So sánh với các cơ chế còn lại:

Mobile apps and partners need one endpoint to call the system; that endpoint is also where requests are authenticated, authorized and throttled before they reach the backend integration.

The mobile app, sales partners and the admin site all call api.mftech.vn. API Gateway runs a series of checks before a request reaches the application code. Pick a scenario and send a request:

Some other requirements:

• Chat between buyers and sellers needs a two-way connection where the backend pushes messages to clients: WebSocket API. With a REST API, each request is independent and no connection is kept open.
• Couriers send their location continuously for order tracking (the “Couriers stream their locations” scenario in the simulation): a REST API uses an AWS service integration to call Kinesis Data Streams PutRecord directly, with no Lambda in between, for Amazon Managed Service for Apache Flink (formerly Amazon Kinesis Data Analytics) to analyze the stream. Lambda only handles individual requests; it is not where data is stored or analyzed.
• Receive transactions from the app, run simple data validation, then process them, with the lowest operational cost: REST API + Lambda for validation, with a serverless backend behind it. There are no servers or containers to patch.

API Gateway offers several ways to authorize users. MFTECH’s new mobile app signs users in through an external OIDC-compliant identity provider; the backend must validate JWTs and scopes with low latency and cost, without writing authentication code. An HTTP API with a JWT authorizer meets this: API Gateway checks the token signature with the public key from the issuer’s jwks_uri, validates the iss, aud and exp claims, and requires the token to include at least one of the route’s scopes; valid claims are passed to the backend. Compare the other mechanisms: