AWS Solutions Architect · บทเรียน

REST API เทียบกับ HTTP API เทียบกับ WebSocket API

ทำความเข้าใจข้อแลกเปลี่ยนระหว่าง REST API (ฟีเจอร์ครบถ้วน), HTTP API (หน่วงต่ำ ต้นทุนต่ำ) และ WebSocket API (สื่อสารสองทิศทาง) พร้อมเลือกใช้ให้เหมาะสม

REST API เทียบกับ HTTP API เทียบกับ WebSocket API เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

เหตุผลที่มี API Gateway

Amazon API Gateway เป็นบริการที่มีการจัดการเต็มรูปแบบ ซึ่งช่วยให้คุณสร้าง เผยแพร่ รักษาความปลอดภัย และตรวจสอบ API ได้ในทุกระดับการใช้งาน บริการนี้ทำหน้าที่เป็น ประตูหน้าสำหรับบริการแบ็กเอนด์ ของคุณ ไม่ว่าจะเป็นฟังก์ชัน Lambda อินสแตนซ์ EC2 แบ็กเอนด์ HTTP หรือบริการ AWS ใด ๆ API Gateway จัดการการควบคุมการรับส่งข้อมูล การอนุญาต การจำกัดอัตรา การตรวจสอบ และการกำหนดเวอร์ชัน API ทำให้แบ็กเอนด์มุ่งเน้นตรรกะทางธุรกิจได้แทนที่จะต้องดูแลโครงสร้างพื้นฐานของ API

REST API: API แบบดั้งเดิมที่มีความสามารถครบถ้วน

REST API (ผลิตภัณฑ์ API Gateway รุ่นดั้งเดิม) มีชุดความสามารถที่กว้างที่สุด ได้แก่ การแปลงคำขอและการตอบกลับด้วย เทมเพลตการแมป การจำกัดอัตราแยกตามเมธอด แผนการใช้งานพร้อมคีย์ API การแคชการตอบกลับ การผสานรวมกับ WAF การติดตามด้วย X-Ray นโยบายทรัพยากร และ TLS แบบร่วมกันด้วยใบรับรองไคลเอ็นต์ REST API รองรับการผสานรวมทุกประเภท ได้แก่ Lambda, HTTP, บริการ AWS, Mock และ Lambda Proxy ให้ใช้ REST API เมื่อจำเป็นต้องใช้ความสามารถขั้นสูง เช่น การแปลงข้อมูล การแคช หรือแผนการใช้งาน

HTTP API: ทางเลือกที่หน่วงต่ำและมีต้นทุนต่ำ

HTTP API ได้รับการออกแบบให้เป็นทางเลือกที่เรียบง่ายกว่า ราคาถูกกว่า และรวดเร็วกว่าสำหรับ REST API รองรับเฉพาะการผสานรวมแบบ Lambda proxy และ HTTP proxy เท่านั้น—ไม่มีการผสานรวมกับบริการ AWS และไม่มี mock ข้อดีสำคัญ ได้แก่ ต้นทุนต่ำกว่า REST API สูงสุด 70% ความหน่วงต่ำกว่า การอนุญาต JWT ด้วย OIDC และ OAuth 2.0 ที่มีมาให้ในตัว และการนำไปใช้งานโดยอัตโนมัติ (จึงไม่จำเป็นต้องมีตัวอนุญาต Lambda สำหรับกรณีการตรวจสอบสิทธิ์ทั่วไป) หากคุณไม่ต้องใช้การแคช แผนการใช้งาน หรือการแปลงคำขอและการตอบกลับ HTTP API เป็นตัวเลือกที่ดีกว่า

# Create a simple HTTP API
aws apigatewayv2 create-api \
  --name 'MyHttpAPI' \
  --protocol-type HTTP \
  --target 'arn:aws:lambda:us-east-1:123456789012:function:MyLambda'

WebSocket API: การสื่อสารแบบสองทิศทางและเรียลไทม์

WebSocket API รักษาการเชื่อมต่อแบบถาวรและสองทิศทางระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ไว้ ต่างจาก HTTP ที่เป็นรูปแบบคำขอและการตอบกลับ WebSocket อนุญาตให้เซิร์ฟเวอร์ ส่งข้อความไปยังไคลเอ็นต์ ที่เชื่อมต่ออยู่ได้ทุกเวลา โดยไม่ต้องให้ไคลเอ็นต์คอยส่งคำขอ API Gateway จัดการการเชื่อมต่อ WebSocket และกำหนดเส้นทางข้อความไปยังฟังก์ชัน Lambda ตามนิพจน์เส้นทาง ให้ใช้ WebSocket API สำหรับแอปพลิเคชันแบบเรียลไทม์ เช่น แอปแชต แดชบอร์ดสด การแก้ไขร่วมกัน เกม และกระดานแสดงราคาหุ้น

เส้นทาง WebSocket และการจัดการการเชื่อมต่อ

WebSocket API มีเส้นทางในตัวสามเส้นทาง ได้แก่ $connect (ทำงานเมื่อไคลเอ็นต์เปิดการเชื่อมต่อ) $disconnect (ทำงานเมื่อการเชื่อมต่อปิดลง) และ $default (ดักจับข้อความที่ไม่ตรงกับเส้นทางใด) คุณสามารถเพิ่มเส้นทางที่กำหนดเอง เช่น sendmessage แล้วแมปกับฟังก์ชัน Lambda ที่ระบุได้ ใช้ API การจัดการ @connections เพื่อส่งข้อความกลับไปยังไคลเอ็นต์ที่เชื่อมต่ออยู่จากฟังก์ชัน Lambda โดยใช้ รหัสการเชื่อมต่อ ของไคลเอ็นต์

# Send a message to a specific WebSocket client from Lambda
import boto3

gw_client = boto3.client(
    'apigatewaymanagementapi',
    endpoint_url='https://abc123.execute-api.us-east-1.amazonaws.com/prod'
)

def lambda_handler(event, context):
    connection_id = event['requestContext']['connectionId']
    gw_client.post_to_connection(
        Data='{"type": "message", "text": "Hello!"}',
        ConnectionId=connection_id
    )

เปรียบเทียบความสามารถ: REST กับ HTTP กับ WebSocket

ความแตกต่างสำคัญโดยสรุป:

REST API: ความสามารถครบถ้วน (การแคช แผนการใช้งาน การแปลงข้อมูล WAF) ต้นทุนสูงกว่า และรองรับการผสานรวมทุกประเภท
HTTP API: รองรับเฉพาะพร็อกซี Lambda/HTTP ราคาถูกลง 70% มีการตรวจสอบสิทธิ์ JWT ในตัว หน่วงต่ำกว่า และไม่มีการแคชหรือแผนการใช้งาน
WebSocket API: การเชื่อมต่อแบบสองทิศทางที่คงอยู่ถาวร รองรับการส่งข้อมูลจากเซิร์ฟเวอร์ และคิดค่าบริการตามจำนวนข้อความทุกหนึ่งล้านข้อความและต่อนาทีของเวลาการเชื่อมต่อ

สำหรับการสอบ SAA-C03: คำถามเกี่ยวกับ HTTP ที่ไม่มีการใช้งานแบบเรียลไทม์หรือความสามารถขั้นสูง → HTTP API การส่งข้อมูลแบบเรียลไทม์จากเซิร์ฟเวอร์ → WebSocket ความสามารถของ API ที่ซับซ้อน → REST API

สเตจและการนำไปใช้งาน

API ของ API Gateway จะถูกนำไปใช้งานใน สเตจ (เช่น dev, staging, prod) แต่ละสเตจมี URL และการตั้งค่าจำกัดอัตราเป็นของตนเอง และสามารถอ้างอิงสแนปช็อตการนำไปใช้งานที่ระบุได้ ใช้ ตัวแปรสเตจ (คล้ายกับตัวแปรสภาพแวดล้อม) เพื่อกำหนดค่าจุดปลายทางแบ็กเอนด์ตามแต่ละสเตจ เช่น ให้สเตจ dev ชี้ไปยังนามแฝง Lambda สำหรับการพัฒนา และ prod ชี้ไปยังนามแฝงสำหรับการใช้งานจริง โดยไม่ต้องทำซ้ำการกำหนดค่า API

# REST API: create a deployment and stage
aws apigateway create-deployment \
  --rest-api-id 'abc123' \
  --stage-name 'prod'

# Set stage variable
aws apigateway update-stage \
  --rest-api-id 'abc123' \
  --stage-name 'prod' \
  --patch-operations 'op=replace,path=/variables/lambdaAlias,value=prod'

ชื่อโดเมนแบบกำหนดเองและการแมปเส้นทางฐาน

โดยค่าเริ่มต้น URL ของ API Gateway จะมี API ID อยู่ด้วย (เช่น abc123.execute-api.us-east-1.amazonaws.com) สำหรับการใช้งานจริง ให้สร้าง ชื่อโดเมนแบบกำหนดเอง ที่มีใบรับรอง ACM รองรับ แล้วแมปชื่อนั้นกับ API และสเตจของคุณ ใช้ การแมปเส้นทางฐาน เพื่อโฮสต์หลาย API ภายใต้โดเมนเดียว (เช่น api.example.com/orders → API คำสั่งซื้อ, api.example.com/users → API ผู้ใช้) ชื่อโดเมนแบบกำหนดเองต้องมีระเบียนนามแฝงของ Route 53 ที่ชี้ไปยังจุดปลายทางของ API Gateway

API แบบปรับให้เหมาะกับเอดจ์ เทียบกับรีเจียนัล เทียบกับไพรเวต

REST API สามารถนำไปใช้งานด้วยประเภทจุดปลายทางสามแบบ: ปรับให้เหมาะกับเอดจ์ (มีส่วนหน้าของ CloudFront เพื่อการกระจายทั่วโลก และเป็นค่าเริ่มต้น), รีเจียนัล (ไม่มี CloudFront ทำให้หน่วงต่ำกว่าสำหรับไคลเอ็นต์ในรีเจียนเดียวกัน หรือเมื่อคุณเพิ่ม CloudFront ของตนเอง) และ ไพรเวต (เข้าถึงได้เฉพาะจากภายใน VPC ผ่านจุดปลายทาง VPC แบบอินเทอร์เฟซ เหมาะสำหรับไมโครเซอร์วิสภายใน) HTTP API รองรับแบบปรับให้เหมาะกับเอดจ์และแบบรีเจียนัล ส่วน WebSocket API รองรับแบบรีเจียนัลและแบบไพรเวต ให้เลือกแบบรีเจียนัลสำหรับ API ที่ใช้งานจากรีเจียนเดียวกัน หรือเมื่อใช้การกระจาย CloudFront แบบกำหนดเอง

การนำไปใช้งานแบบแคนารีด้วย API Gateway

REST API ของ API Gateway รองรับ การนำไปใช้งานแบบแคนารี บนสเตจ คุณสามารถกำหนดเส้นทางให้เปอร์เซ็นต์หนึ่งของการรับส่งข้อมูลไปยังการนำไปใช้งานแบบแคนารี (เวอร์ชันใหม่) ขณะที่ส่วนที่เหลือไปยังการนำไปใช้งานจริง ให้ตรวจสอบอัตราข้อผิดพลาดและความหน่วงของแคนารี หากมีเสถียรภาพ ให้เลื่อนระดับเป็น 100% หากเกิดปัญหา ให้ย้อนกลับด้วยการตั้งค่าน้ำหนักแคนารีเป็น 0 วิธีนี้คล้ายกับการกำหนดเส้นทางแบบถ่วงน้ำหนักของนามแฝง Lambda และช่วยให้ปรับปรุง API อย่างปลอดภัยและค่อยเป็นค่อยไปโดยไม่ต้องสลับสภาพแวดล้อมแบบ blue/green

การเลือกประเภท API ที่เหมาะสมสำหรับการสอบ

คำสำคัญในคำถามสอบ SAA-C03 สำหรับระบุประเภท API: 'API แบบเรียบง่ายและคุ้มค่า' → HTTP API; 'สองทิศทางแบบเรียลไทม์' หรือ 'การส่งข้อมูลจากเซิร์ฟเวอร์' หรือ 'แชต' → WebSocket API; 'การแปลงคำขอ', 'แผนการใช้งาน', 'การจำกัดอัตราด้วยคีย์ API', 'การแคชการตอบกลับ' → REST API เมื่อคำถามเพียงต้องการ 'เปิดให้ใช้ Lambda เป็นจุดปลายทาง HTTP ด้วยต้นทุนต่ำ' HTTP API เป็นคำตอบที่เหมาะสมกว่า เมื่อคำถามเกี่ยวข้องกับความสามารถด้านการจัดการ API ที่ซับซ้อนหรือพาร์ทเนอร์ โดยทั่วไป REST API จะเป็นคำตอบที่ถูกต้อง

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

ทบทวนบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า: REST API มีชุดความสามารถของ API Gateway ครบถ้วน (การแคช การแปลงข้อมูล แผนการใช้งาน WAF) แต่มีต้นทุนสูงกว่า HTTP API ถูกกว่า 70% มีการตรวจสอบสิทธิ์ JWT ในตัวและมีความหน่วงต่ำกว่า จึงเหมาะสำหรับกรณีพร็อกซี Lambda/HTTP ที่ไม่ต้องใช้ความสามารถขั้นสูง และ WebSocket API เปิดให้สื่อสารแบบเรียลไทม์ด้วยการส่งข้อมูลจากเซิร์ฟเวอร์ผ่านการเชื่อมต่อถาวร เหมาะสำหรับแอปแชต เกม และแอปพลิเคชันข้อมูลสด ต่อไป เราจะสำรวจการผสานรวม API Gateway กับ Lambda แบ็กเอนด์ HTTP และการตอบกลับแบบจำลอง

คำถามที่พบบ่อย

บทเรียน “REST API เทียบกับ HTTP API เทียบกับ WebSocket API” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “REST API เทียบกับ HTTP API เทียบกับ WebSocket API” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “REST API เทียบกับ HTTP API เทียบกับ WebSocket API”

ทำความเข้าใจข้อแลกเปลี่ยนระหว่าง REST API (ฟีเจอร์ครบถ้วน), HTTP API (หน่วงต่ำ ต้นทุนต่ำ) และ WebSocket API (สื่อสารสองทิศทาง) พร้อมเลือกใช้ให้เหมาะสม คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “REST API เทียบกับ HTTP API เทียบกับ WebSocket API” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

REST API เทียบกับ HTTP API เทียบกับ WebSocket API
การผสานรวม: Lambda, HTTP และแบบจำลอง
การอนุญาต: IAM, ตัวอนุญาต Lambda และ Cognito
การจำกัดอัตรา การแคช และแผนการใช้งาน

← กลับไปที่ AWS Solutions Architect