การผสานรวม: Lambda, HTTP และแบบจำลอง
เชื่อมเมธอด API Gateway เข้ากับการผสานรวมแบบพร็อกซีของ Lambda ปลายทาง HTTP ต้นทาง และการผสานรวมแบบจำลองสำหรับการทดสอบ
การผสานรวม: Lambda, HTTP และแบบจำลอง เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
ภาพรวมประเภทการผสานรวมของ API Gateway
เมธอดทุกรายการของ API Gateway ต้องมี การผสานรวมกับแบ็กเอนด์ ซึ่งเป็นระบบที่ประมวลผลคำขอและส่งการตอบกลับ API Gateway รองรับการผสานรวม 5 ประเภท ได้แก่ Lambda Proxy, Lambda Custom, HTTP Proxy, HTTP Custom และ Mock HTTP API รองรับเฉพาะ Lambda Proxy และ HTTP Proxy ส่วน REST API รองรับทั้งหมด การเลือกประเภทการผสานรวมที่เหมาะสมจะกำหนดระดับการควบคุมที่คุณมีต่อการแปลงคำขอและการตอบกลับ
การผสานรวมแบบ Lambda Proxy
ในการผสานรวมแบบ Lambda Proxy API Gateway จะส่งคำขอ HTTP ทั้งหมดไปยัง Lambda ในรูปออบเจ็กต์เหตุการณ์ที่มีโครงสร้าง ซึ่งรวมส่วนหัว สตริงคำค้นหา พารามิเตอร์เส้นทาง เนื้อหา และบริบท ฟังก์ชัน Lambda ของคุณมีหน้าที่ส่งคืนออบเจ็กต์การตอบกลับที่จัดรูปแบบอย่างถูกต้อง โดยมี statusCode, headers และ body รูปแบบนี้เป็นรูปแบบที่ง่ายและใช้กันมากที่สุด ไม่ต้องใช้เทมเพลตการแมป และ Lambda ของคุณควบคุมการตอบกลับได้ทั้งหมด
def lambda_handler(event, context):
# event.httpMethod, event.path, event.queryStringParameters
# event.headers, event.body
user_id = event['pathParameters']['userId']
return {
'statusCode': 200,
'headers': {'Content-Type': 'application/json'},
'body': '{"userId": "' + user_id + '", "name": "Alice"}'
}การผสานรวมแบบ Lambda ที่ไม่ใช่พร็อกซี (กำหนดเอง)
ในการผสานรวมแบบ Lambda Non-Proxy (การผสานรวมแบบกำหนดเอง) API Gateway ใช้ เทมเพลตการแมป (Apache Velocity Template Language, VTL) เพื่อแปลงคำขอก่อนส่งไปยัง Lambda และแปลงการตอบกลับของ Lambda ก่อนส่งคืนให้ไคลเอ็นต์ ฟังก์ชัน Lambda ของคุณจะได้รับเพย์โหลดแบบกำหนดเองที่สะอาด ไม่ใช่เหตุการณ์ดิบจาก API Gateway วิธีนี้แยกข้อกังวลด้านการรับส่งข้อมูลออกจากตรรกะทางธุรกิจ แต่ต้องดูแลเทมเพลต VTL ใช้การผสานรวมแบบกำหนดเองเมื่อต้องการแยกสัญญาระหว่าง API กับแบ็กเอนด์อย่างเคร่งครัด
## Integration Request Mapping Template (VTL)
#set($inputRoot = $input.path('$'))
{
'userId': '$input.params('userId')',
'action': '$inputRoot.action',
'timestamp': '$context.requestTime'
}การผสานรวมแบบ HTTP Proxy
การผสานรวมแบบ HTTP Proxy จะส่งต่อคำขอโดยตรงไปยัง จุดปลายทาง HTTP ภายนอก (อาจเป็นอินสแตนซ์ EC2, ALB, เซิร์ฟเวอร์ภายในองค์กร หรือ URL สาธารณะใด ๆ) โดยไม่แปลงข้อมูล API Gateway จะส่งต่อคำขอและส่งการตอบกลับจากแบ็กเอนด์คืนให้ไคลเอ็นต์ วิธีนี้เหมาะอย่างยิ่งสำหรับการย้ายแบ็กเอนด์ REST ที่มีอยู่มาไว้หลัง API Gateway เพื่อเพิ่มการจำกัดอัตรา การตรวจสอบ และคีย์ API โดยไม่ต้องเปลี่ยนโค้ดแบ็กเอนด์ รองรับแบ็กเอนด์ HTTPS ที่มีการตรวจสอบใบรับรอง
# Create HTTP proxy integration via REST API
aws apigateway put-integration \
--rest-api-id 'abc123' \
--resource-id 'xyz789' \
--http-method GET \
--type HTTP_PROXY \
--integration-http-method GET \
--uri 'https://my-backend.example.com/api/users/{userId}'การผสานรวมแบบ HTTP กำหนดเอง (ไม่ใช่พร็อกซี)
การผสานรวมแบบ HTTP Custom จะส่งต่อไปยังจุดปลายทาง HTTP ภายนอกเช่นกัน แต่ใช้เทมเพลตการแมปเพื่อแปลงทั้งคำขอที่ส่งไปยังแบ็กเอนด์และการตอบกลับที่ส่งกลับมา วิธีนี้มีประโยชน์เมื่ออินเทอร์เฟซ API กับ API ของแบ็กเอนด์มีสัญญาแตกต่างกัน คุณสามารถแปลงการเรียก REST API เป็น SOAP รุ่นเก่าหรือรูปแบบกำหนดเอง และแปลงการตอบกลับจากแบ็กเอนด์กลับเป็นโครงสร้าง JSON ที่สะอาดสำหรับไคลเอ็นต์ วิธีนี้เพิ่มความซับซ้อน แต่ให้การควบคุมมากที่สุดสำหรับการผสานรวมกับระบบรุ่นเก่า
การผสานรวมกับบริการ AWS
การผสานรวมแบบ AWS Service เชื่อมต่อ API Gateway กับบริการ AWS โดยตรงโดยไม่ต้องมี Lambda คั่นกลาง ตัวอย่างเช่น คุณสามารถกำหนดค่าจุดปลายทาง POST ที่เขียนข้อความไปยัง SQS เผยแพร่ไปยัง SNS หรือเริ่มการทำงานของ Step Functions ได้โดยตรง วิธีนี้ลดความหน่วงและไม่ต้องเสียค่าใช้ฟังก์ชัน Lambda สำหรับการกำหนดเส้นทางแบบง่าย การผสานรวมนี้ต้องกำหนดค่าบทบาท IAM และเทมเพลตการแมปเพื่อจัดรูปแบบการเรียก API ของ AWS ให้ถูกต้อง
# Direct API Gateway → SQS integration
# Integration Request URI:
https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue
# Integration Request Body Mapping Template:
Action=SendMessage&MessageBody=$input.bodyการเชื่อมต่อแบบ Mock สำหรับการพัฒนาและการทดสอบ
การเชื่อมต่อแบบ Mock จะกำหนดค่า API Gateway ให้ส่งการตอบกลับที่กำหนดไว้ล่วงหน้าโดยไม่เรียกใช้แบ็กเอนด์ คุณกำหนดการตอบกลับไว้ในแม่แบบการแมปการตอบกลับของการเชื่อมต่อ การเชื่อมต่อแบบ Mock เหมาะอย่างยิ่งสำหรับ: การพัฒนา API ก่อนสร้างแบ็กเอนด์ (ทีมส่วนหน้าสามารถเริ่มงานได้ทันที) การทดสอบหน่วยของการกำหนดค่า API การส่งส่วนหัว CORS มาตรฐาน หรือการจัดเตรียมตัวจำลองสำหรับพาร์ทเนอร์ภายนอกในระหว่างการพัฒนา นอกจากนี้ยังใช้ปลายทางแบบ Mock เพื่อบล็อก API เวอร์ชันที่เลิกใช้แล้วได้ โดยส่งการตอบกลับ 410 Gone
# Integration Response for Mock
# Integration Response Mapping Template:
{
'statusCode': 200,
'message': 'This is a mock response',
'timestamp': '$context.requestTime'
}
# Method Response: map status code 200 to this templateการกำหนดค่า CORS ใน API Gateway
CORS (การแชร์ทรัพยากรข้ามต้นทาง) ต้องเปิดใช้งานเมื่อไคลเอ็นต์เบราว์เซอร์จากโดเมนหนึ่งเรียก API ของคุณบนอีกโดเมนหนึ่ง HTTP API มีการกำหนดค่า CORS ในคลิกเดียว ส่วน REST API ต้องสร้าง เมธอด OPTIONS พร้อมการเชื่อมต่อแบบ Mock ที่ส่งส่วนหัว CORS ที่จำเป็น (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers) การเชื่อมต่อพร็อกซีของฟังก์ชันแลมบ์ดายังต้องให้ฟังก์ชันแลมบ์ดาของคุณส่งส่วนหัว CORS ในการตอบกลับด้วย
# HTTP API CORS config (simple)
aws apigatewayv2 update-api \
--api-id 'abc123' \
--cors-configuration '{
"AllowOrigins": ["https://myapp.example.com"],
"AllowMethods": ["GET", "POST", "OPTIONS"],
"AllowHeaders": ["Content-Type", "Authorization"]
}'การตรวจสอบคำขอใน REST API
REST API รองรับการตรวจสอบคำขอ: API Gateway สามารถตรวจสอบว่าพารามิเตอร์สตริงคำค้นหา ส่วนหัว และสคีมาของเนื้อหาคำขอที่จำเป็นมีอยู่และจัดรูปแบบอย่างถูกต้องหรือไม่ ก่อนเรียกใช้การเชื่อมต่อแบ็กเอนด์ วิธีนี้ช่วยลดการเรียกใช้ฟังก์ชันแลมบ์ดาที่ไม่จำเป็นจากคำขอที่มีรูปแบบไม่ถูกต้อง และส่งข้อผิดพลาด 400 ตามมาตรฐานโดยอัตโนมัติ กำหนดแบบจำลองคำขอโดยใช้ JSON Schema แล้วแนบแบบจำลองนั้นกับเมธอดเพื่อเปิดใช้การตรวจสอบเนื้อหา REST API ไม่มีการตรวจสอบคำขอ
หมดเวลาของการเชื่อมต่อ
API Gateway มีเวลาหมดเวลาของการเชื่อมต่อเริ่มต้น 29 วินาทีสำหรับ REST API และ HTTP API (เป็นค่าสูงสุดสำหรับ REST API และเป็นค่าคงที่สำหรับพร็อกซีของ HTTP API) หากแบ็กเอนด์ใช้เวลานานกว่า 29 วินาที API Gateway จะส่งข้อผิดพลาด 504 Gateway Timeout ซึ่งหมายความว่าฟังก์ชันแลมบ์ดาที่ถูกเรียกใช้งานแบบพร้อมกันผ่าน API Gateway ต้องทำงานเสร็จภายใน 29 วินาที แม้ว่าฟังก์ชันแลมบ์ดาเองจะรองรับเวลาหมดเวลาสูงสุด 15 นาทีก็ตาม สำหรับการดำเนินการที่ใช้เวลานาน ให้ใช้รูปแบบแบบอะซิงโครนัส: API Gateway เรียกใช้ฟังก์ชันแลมบ์ดา ซึ่งเริ่มงานแบบอะซิงโครนัสและส่ง ID งานกลับทันที
การเลือกประเภทการเชื่อมต่อที่เหมาะสม
แนวทางเลือกประเภทการเชื่อมต่อ: พร็อกซีของฟังก์ชันแลมบ์ดา: ใช้บ่อยที่สุด เรียบง่ายที่สุด และควบคุมคำขอได้ทั้งหมดในฟังก์ชันแลมบ์ดา; การเชื่อมต่อแบบกำหนดเองของฟังก์ชันแลมบ์ดา: ใช้เมื่อต้องการแปลงคำขอหรือการตอบกลับในชั้นเกตเวย์; พร็อกซี HTTP: ใช้กับแบ็กเอนด์ HTTP ที่มีอยู่แล้วหรือสถานการณ์ย้ายระบบ; การเชื่อมต่อ HTTP แบบกำหนดเอง: ใช้แปลงรูปแบบ API รุ่นเก่า; บริการ AWS: ใช้ตัดฟังก์ชันแลมบ์ดาออกสำหรับการกำหนดเส้นทางอย่างง่ายไปยัง SQS/SNS/DynamoDB; Mock: ใช้เป็นตัวจำลองสำหรับการพัฒนาและการตรวจสอบล่วงหน้าของ CORS สำหรับการสอบ SAA-C03 รูปแบบพร็อกซีของฟังก์ชันแลมบ์ดาและพร็อกซี HTTP เป็นรูปแบบที่ออกสอบบ่อยที่สุด
ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า: การเชื่อมต่อแบบ พร็อกซีของฟังก์ชันแลมบ์ดาจะส่งคำขอทั้งหมดไปยังฟังก์ชันแลมบ์ดา ซึ่งเป็นผู้ควบคุมการตอบกลับ จึงเป็นการเชื่อมต่อที่ง่ายและใช้บ่อยที่สุด; พร็อกซี HTTPจะส่งต่อคำขอไปยังแบ็กเอนด์ HTTP ที่มีอยู่แล้ว เพื่อเพิ่มความสามารถของ API Gateway โดยไม่ต้องเปลี่ยนแปลงแบ็กเอนด์; และการเชื่อมต่อแบบ Mockจะส่งการตอบกลับที่กำหนดไว้ล่วงหน้าสำหรับการพัฒนาและการทดสอบส่วนหน้าโดยไม่ต้องมีโครงสร้างพื้นฐานแบ็กเอนด์ บทถัดไป เราจะสำรวจการอนุญาตของ API Gateway ด้วย IAM, ตัวอนุญาตของฟังก์ชันแลมบ์ดา และ Cognito
คำถามที่พบบ่อย
บทเรียน “การผสานรวม: Lambda, HTTP และแบบจำลอง” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การผสานรวม: Lambda, HTTP และแบบจำลอง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การผสานรวม: Lambda, HTTP และแบบจำลอง”
เชื่อมเมธอด API Gateway เข้ากับการผสานรวมแบบพร็อกซีของ Lambda ปลายทาง HTTP ต้นทาง และการผสานรวมแบบจำลองสำหรับการทดสอบ คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “การผสานรวม: Lambda, HTTP และแบบจำลอง” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- REST API เทียบกับ HTTP API เทียบกับ WebSocket API
- การผสานรวม: Lambda, HTTP และแบบจำลอง
- การอนุญาต: IAM, ตัวอนุญาต Lambda และ Cognito
- การจำกัดอัตรา การแคช และแผนการใช้งาน