แผนการเรียนรู้
/
สัปดาห์ที่ 2 -- ส่วนที่ 1

สถาปัตยกรรม REST API และเครื่องมือ HTTPie

RESTful API Design, HTTPie CLI / Desktop & Scoop Installation (1145101)

เป้าหมายการเรียนรู้สัปดาห์ที่ 2

1. เข้าใจหลักการและข้อกำหนดของสถาปัตยกรรม REST API
2. ออกแบบ Resource-Oriented Endpoints และเลือกใช้ HTTP Verbs / Status Codes
3. ติดตั้ง HTTPie CLI & Desktop ผ่าน Package Manager Scoop
4. ฝึกส่งคำสั่งและทดสอบการรับส่งข้อมูล JSON Payload ด้วย HTTPie
รายวิชา การพัฒนาเว็บแอปพลิเคชันเต็มรูปแบบพื้นฐาน -- 3 หน่วยกิต 3(2-2-5)

เค้าโครงการเรียนรู้ประจำสัปดาห์

Week 2 Detailed Agenda & Outline

ส่วนที่ 1
REST Overview
ความหมาย ข้อกำหนดหลัก และการเปรียบเทียบ API Architectures
ส่วนที่ 2
Endpoint Design
Resource Naming, CRUD Mapping, Nested URLs & Query Params
ส่วนที่ 3
Status & Payload
Status Codes, JSON Structure, Error Handling & Versioning
ส่วนที่ 4
Scoop & HTTPie
การติดตั้ง Scoop, HTTPie CLI & Desktop และเปรียบเทียบ cURL/Postman
ส่วนที่ 5
Hands-on Lab
ฝึกทดสอบ Public API, ออกแบบ API Spec และสรุปการบ้าน

REST คืออะไร? (Representational State Transfer)

Architectural Style for Distributed Hypermedia Systems

REST ไม่ใช่โปรโตคอลหรือมาตรฐานบังคับ แต่เป็น สถาปัตยกรรมระดับแนวทางปฏิบัติ (Architectural Style) ที่ถูกนำเสนอโดย Roy Fielding ในปี 2000 สำหรับสร้าง Web Services ที่ขยายระบบง่าย (Scalable) และสื่อสารกันผ่านมาตรฐานโปรโตคอล HTTP

6 ข้อกำหนดสำคัญของสถาปัตยกรรม REST (REST Constraints):

1. Client-Server
แยกส่วน UI และ Data Management ชัดเจน
2. Stateless
ไม่เก็บ Session Context บน Server
3. Cacheable
Response ต้องระบุว่าเก็บแคชได้หรือไม่
4. Uniform Interface
ใช้มาตรฐาน URI/HTTP เดียวกันทั้งระบบ
5. Layered System
ต่อซ้อนชั้น Proxy, Load Balancer ได้
6. Code on Demand
ส่งโค้ดไปรันฝั่ง Client ได้ (Optional)

การเปรียบเทียบสถาปัตยกรรม API สมัยใหม่

REST vs RPC / gRPC vs GraphQL

REST API
Resource-Based
  • • เน้นการจัดการทรัพยากร (Nouns) ผ่าน HTTP Verbs
  • • เข้ากันได้ดีกับเว็บบราว์เซอร์ และทำ HTTP Caching ง่าย
  • • มาตรฐานหลักในการพัฒนา Web & Mobile Services
RPC / gRPC
Action-Based
  • • เน้นการเรียกใช้ฟังก์ชัน/คำสั่งกริยา (Verbs/Remote Procedures)
  • • ประมวลผลรวดเร็วมากด้วย Binary Protocol (Protobuf)
  • • นิยมใช้สื่อสารระหว่าง Microservices หลังบ้าน
GraphQL
Query-Based
  • • Client กำหนดโครงสร้างข้อมูลที่ต้องการตอบกลับได้เอง
  • • แก้ปัญหา Over-fetching และ Under-fetching
  • • เหมาะสำหรับระบบที่มี UI ซับซ้อนและข้อมูลหลายความสัมพันธ์
สัปดาห์ที่ 2 -- ส่วนที่ 2

การออกแบบเน้นทรัพยากร (Resource-Oriented Design)

Shifting from Verbs to Nouns in Web Development

❌ RPC-style Approach (เน้นคำสั่ง)

สร้าง URL แยกตามการทำงานแต่ละฟังก์ชัน:

POST /getUsers
POST /createProduct
POST /updateProductPrice?id=10
POST /deleteUser
✓ RESTful Approach (เน้นทรัพยากร)

ใช้ URL ระบุทรัพยากร และใช้ HTTP Verb ระบุการกระทำ:

GET /api/v1/users
POST /api/v1/products
PATCH /api/v1/products/10
DELETE /api/v1/users/5

กฎการตั้งชื่อ REST Endpoints (Naming Conventions)

Best Practices for Clean & Standard URLs

1. ใช้คำนามพหูพจน์ (Plural Nouns)

แทนกลุ่มชุดทรัพยากร เช่น `/users`, `/products`, `/orders` แทนคำเอกพจน์

2. ใช้ตัวพิมพ์เล็กและ Hyphen

ใช้ตัวพิมพ์เล็กทั้งหมด เชื่อมคำด้วย `-` (kebab-case) เช่น `/order-items` ห้ามใช้ `camelCase` หรือ `_`

3. ห้ามใส่คำกริยาใน URL Path

ห้ามใส่คำว่า `/create-user` หรือ `/delete-item` ให้ใช้ HTTP Method แทนการระบุกริยา

4. ระบุตัวแทนด้วย Identifier ID

เข้าถึงข้อมูลเฉพาะชิ้นโดยการต่อท้ายด้วย ID เช่น `/users/102` หรือ `/orders/88`

การจับคู่ HTTP Verbs กับ CRUD Operations

HTTP Methods & Resource Endpoint Matrix

HTTP Verb CRUD Operation Example Endpoint Safe? Idempotent?
GET Read (ดึงข้อมูล) /api/v1/articles Yes Yes
POST Create (สร้างข้อมูลใหม่) /api/v1/articles No No
PUT Update (ทดแทนทั้งหมด) /api/v1/articles/10 No Yes
PATCH Update (แก้ไขบางส่วน) /api/v1/articles/10 No No
DELETE Delete (ลบข้อมูล) /api/v1/articles/10 No Yes

การจัดการทรัพยากรเกี่ยวเนื่อง (Nested Resources)

Modeling Parent-Child Relationships in URLs

การเชื่อมโยงข้อมูลที่มีความสัมพันธ์กัน:

ดึงความคิดเห็นทั้งหมดใต้บทความ ID: 45
GET /api/v1/articles/45/comments
สร้างความคิดเห็นใหม่ใต้บทความ ID: 45
POST /api/v1/articles/45/comments
คำแนะนำ: หลีกเลี่ยงการซ้อนตำแหน่งเกิน 2 ระดับ เช่น /authors/1/books/5/chapters/12 ให้ปรับเป็น /chapters/12 โดยตรงเพื่อความเรียบง่าย

Filtering, Sorting & Pagination ด้วย Query Parameters

Managing Collection Datasets without Changing Resource URLs

1. Filtering (กรองข้อมูล)

ส่งเงื่อนไขกรองเฉพาะรายการที่เข้าเกณฑ์:

GET /products?status=active&category=tech
2. Sorting (เรียงลำดับ)

กำหนดฟิลด์และทิศทางในการเรียงลำดับ:

GET /products?sort=-created_at,price
3. Pagination (แบ่งหน้า)

แบ่งการส่งข้อมูลออกเป็นก้อนเพื่อลดภาระระบบ:

GET /products?page=2&limit=20
สัปดาห์ที่ 2 -- ส่วนที่ 3

HTTP Status Codes ในสถาปัตยกรรม REST

Meaningful Response Statuses in API Design

200 OK & 201 Created

`200` สำหรับดึง/แก้ไขสำเร็จ และ `201` สำหรับคำสั่งสร้างทรัพยากรใหม่สำเร็จ (POST)

204 No Content

ประมวลผลสำเร็จแต่ไม่มี Response Payload ส่งกลับ (นิยมใช้กับคำสั่ง DELETE)

400 Bad Request & 422 Unprocessable

`400` สำหรับไวยากรณ์ผิดพลาด และ `422` สำหรับกรณีข้อมูลฟอร์มไม่ผ่านการ Validation

401 Unauthorized & 403 Forbidden

`401` เมื่อผู้ใช้ยังไม่ได้ Login และ `403` เมื่อ Login แล้วแต่ไม่มีสิทธิ์เข้าถึงทรัพยากร

หลักการออกแบบ JSON Payload

JSON Data Formatting & Naming Conventions

// Good JSON Payload Example
{
"id": 102,
"first_name": "Somchai",
"is_active": true,
"roles": ["developer", "admin"],
"created_at": "2026-09-10T08:00:00Z"
}
1. Consistent Key Naming
ตกลงรูปแบบ Key ร่วมกันให้ชัดเจนในทีม (นิยมใช้ `snake_case` สำหรับ Django/Python หรือ `camelCase` สำหรับ JS)
2. Proper Data Types
ใช้ Data Types ให้ถูกต้อง เช่น Boolean (`true/false`), Numbers (`102`) โดยไม่ต้องครอบด้วย String Quote
3. ISO 8601 Date Format
ส่งข้อมูลวันที่และเวลาในรูปแบบมาตรฐานสากล ISO 8601 เช่น `2026-09-10T08:00:00Z`

โครงสร้างการตอบกลับข้อผิดพลาด (Error Handling Schema)

Predictable Error Responses for Client Integration

// Standard Error Response Body
{
"error_code": "VALIDATION_FAILED",
"message": "Invalid form submission data.",
"details": [
{"field": "email", "issue": "Email is already registered."},
{"field": "password", "issue": "Password is too short."}
]
}

ทำไมต้องทำ Error Schema ให้เป็นมาตรฐาน?

• ช่วยให้ทีมพัฒนาฝั่ง Frontend หรือ Mobile App เขียนสคริปต์ดักจับและแสดงข้อผิดพลาดบน UI ได้อย่างสม่ำเสมอ

• สามารถระบุรายละเอียดฟิลด์ที่ไม่ผ่านเงื่อนไข Validation ช่วยเพิ่มประสบการณ์ผู้ใช้ที่ดีขึ้น

กลยุทธ์การจัดการเวอร์ชันของ API (API Versioning)

Managing Backward Compatibility in Growing Applications

1. URI Path Versioning (นิยมที่สุด)

ระบุเวอร์ชันลงในโครงสร้าง URL โดยตรง อ่านง่าย และทดสอบได้สะดวกรวดเร็ว:

https://api.demo.com/v1/products
https://api.demo.com/v2/products
2. Header Versioning

ระบุเวอร์ชันผ่าน Request Header เช่น `Accept` หรือ Custom Header:

Accept: application/vnd.demo.v2+json

การยืนยันตัวตนแบบ Stateless ใน REST APIs

Token-Based Authentication & Authorization Headers

กลไกการยืนยันตัวตนด้วย Bearer Token (JWT):

1. Authentication
User ส่ง Username/Password ไปยัง `/api/login`
2. Issue Token
Server ตรวจสอบถูกต้อง แล้วออก Access Token คืนกลับไป
3. Authorization Header
Client แนบ Token ไปกับ Authorization Header ทุกครั้ง
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
สัปดาห์ที่ 2 -- ส่วนที่ 4

แนะนำ Scoop Package Manager สำหรับ Windows

Command-Line Software Installer for Developers

Scoop คืออะไร?

Scoop เป็น Package Manager บน Windows ที่ช่วยให้เราติดตั้ง จัดการ และอัปเดตเครื่องมือพัฒนาซอฟต์แวร์ผ่าน PowerShell ได้ง่ายๆ โดยไม่ต้องกด GUI Wizard หน้าต่างป๊อปอัปให้ยุ่งยาก

ขั้นตอนการติดตั้ง Scoop บน PowerShell:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

การติดตั้ง HTTPie CLI & Desktop ด้วย Scoop

Installing Modern API Testing Tools in One Command

# 1. ติดตั้ง HTTPie CLI (Command-Line Interface)
scoop install httpie
# 2. ติดตั้ง HTTPie Desktop (Graphical User Interface)
scoop bucket add extras
scoop install httpie-desktop
# 3. ตรวจสอบเวอร์ชันหลังติดตั้งสำเร็จ
http --version
เพียงเท่านี้ เครื่องคอมพิวเตอร์ของคุณจะพร้อมใช้งานทั้งเครื่องมือทดสอบ API แบบ CLI บน Terminal และแบบ Desktop GUI Application

พื้นฐานการใช้งาน HTTPie CLI

Human-Friendly Command-Line HTTP Client

ทำไมต้องเลือกใช้ HTTPie?

• ไวยากรณ์สั้นกระชับ เป็นธรรมชาติ สื่อความหมายชัดเจน

• จัดรูปแบบสีเน้นข้อความ (Syntax Highlighting) และจัดย่อหน้า JSON อัตโนมัติ

• กำหนดค่า `Content-Type: application/json` ให้อัตโนมัติเมื่อส่งป้อนข้อมูล

// โครงสร้างไวยากรณ์มาตรฐาน
http [METHOD] URL [ITEM...]
// ตัวอย่างคำสั่งส่ง GET Request แบบง่าย
http GET api.demo.com/v1/products

ตัวอย่างคำสั่ง HTTPie CLI ในรูปแบบต่างๆ

HTTPie CLI Usage Examples: Parameters, Headers & JSON

# 1. ส่ง Query Parameters (ใช้สัญลักษณ์ ==)
http GET api.demo.com/products category==tech limit==10
# 2. ส่ง JSON Payload สำหรับสร้างข้อมูลใหม่ (ใช้สัญลักษณ์ =)
http POST api.demo.com/products title="Keyboard" price:=1500 is_stock:=true
# 3. แนบ Request Header & Authorization Token (ใช้สัญลักษณ์ :)
http GET api.demo.com/profile "Authorization:Bearer token123"
# 4. ดูเฉพาะ Response Headers (-h) หรือเฉพาะ Body (-b)
http -h GET api.demo.com/products

รู้จักเครื่องมือ HTTPie Desktop (GUI Interface)

Visual & Intuitive API Testing Environment

1. Visual Request Builder

สร้าง Request สลับแท็บ Param, Header, Body (JSON/Form) ได้สะดวกรวดเร็วผ่านหน้าจอ GUI

2. Collections & Spaces

จัดกลุ่มรายการ API Endpoints แยกตามโปรเจกต์ เพิ่มความสะดวกในการทำงานร่วมกันเป็นทีม

3. Environment Variables

ตั้งค่าตัวแปรสภาพแวดล้อม เช่น `{{base_url}}` หรือ `{{token}}` สำหรับสลับทดสอบระหว่าง Local/Prod

ตารางเปรียบเทียบ cURL vs HTTPie vs Postman

API Testing Tools Comparison Matrix

คุณสมบัติ cURL HTTPie (CLI & Desktop) Postman
Interface Support CLI เท่านั้น CLI & Desktop App Desktop App & Cloud
ความง่ายของไวยากรณ์ CLI ซับซ้อน ต้องจดจำตัวแปรดิบ อ่านง่าย เป็นธรรมชาติ ไม่มี CLI หลัก (ต้องใช้ Newman)
การจัดรูปแบบ JSON/Color ข้อความเปล่า ต้องต่อท่อ `jq` สีสันสวยงาม & จัดย่อหน้าในตัว สวยงามผ่าน GUI
การติดตั้งบน Windows มีในตัว (PowerShell) ติดตั้งง่ายผ่าน Scoop ดาวน์โหลดไฟล์ `.exe` ขนาดใหญ่
สัปดาห์ที่ 2 -- ส่วนที่ 5

ปฏิบัติการทดสอบ Public REST APIs ด้วย HTTPie

Hands-on Lab Exercise: Testing Live Mock Services

โจทย์ทดสอบปฏิบัติการในชั้นเรียน:

ใช้ **HTTPie CLI** บน Terminal หรือ **HTTPie Desktop** ยิง Request ไปยัง Public API (https://jsonplaceholder.typicode.com):

# 1. อ่านโพสต์ทั้งหมด -> http GET https://jsonplaceholder.typicode.com/posts
# 2. สร้างโพสต์ใหม่ -> http POST https://jsonplaceholder.typicode.com/posts title="My Post" userId:=1
# 3. ลบโพสต์ ID 1 -> http DELETE https://jsonplaceholder.typicode.com/posts/1

กิจกรรมออกแบบโครงสร้าง RESTful API Specification

Small Group Workshop: E-Commerce / Store API Design

โจทย์เวิร์กชอปกลุ่มย่อย:

ออกแบบโครงสร้าง Endpoints สำหรับระบบร้านค้าออนไลน์ (Store System) ที่ประกอบด้วยทรัพยากร **Products** และ **Orders**

• กำหนด HTTP Method, URL Path และ Status Code ให้ถูกต้องตามมาตรฐาน REST

• เขียนโครงสร้าง JSON Request / Response Body จำลอง

// ตัวอย่างผลลัพธ์ที่ต้องส่ง
GET /api/v1/products
POST /api/v1/products
GET /api/v1/users/12/orders
DELETE /api/v1/orders/99

สรุปประเด็นสำคัญสัปดาห์ที่ 2

Week 2 Key Takeaways & Summary

REST Constraints

สถาปัตยกรรมแบบ Stateless, Client-Server และ Uniform Interface

Resource URLs

ใช้คำนามพหูพจน์ระบุทรัพยากร จับคู่ CRUD กับ HTTP Verbs

Scoop Installation

ใช้ Scoop บน Windows ติดตั้งเครื่องมือสาย Dev ได้สะดวกผ่าน Terminal

HTTPie Tools

ใช้ HTTPie CLI & Desktop ทดสอบการรับส่ง JSON Payload อย่างมีประสิทธิภาพ

งานปฏิบัติการและการศึกษาด้วยตนเอง

Weekly Assignment & Self-Study Guide (5 Hours/Week)

1. งานปฏิบัติการประจำสัปดาห์ (Lab 2)

  • • ติดตั้ง Scoop, HTTPie CLI และ HTTPie Desktop บนเครื่องคอมพิวเตอร์ตนเอง
  • • เขียนสคริปต์คำสั่ง HTTPie CLI ทดสอบการยิง Request 5 รูปแบบ แล้วจับภาพหน้าจอผลลัพธ์ส่งในรายงาน

2. หัวข้อศึกษาด้วยตนเอง (5 ชม./สัปดาห์)

  • • ศึกษาบทความเปรียบเทียบสถาปัตยกรรม Monolithic vs Microservices เพื่อเตรียมตัวสำหรับสัปดาห์ถัดไป
  • • ฝึกใช้ตัวแปร Environment ใน HTTPie Desktop เพื่อทดสอบ API Endpoints
เกริ่นนำบทเรียนครั้งต่อไป

สัปดาห์ที่ 3: System Design Overview (Part I)

Monolithic vs Microservices Architecture & Architectural Trade-offs

หัวข้อที่จะเรียนรู้ในสัปดาห์ที่ 3:

  • • ภาพรวม System Design: การจัดวางสถาปัตยกรรมระบบเว็บแอปพลิเคชันและการวางเลเยอร์ (Frontend, Backend, Database)
  • • Monolith vs Microservices: การเปรียบเทียบข้อดี ข้อเสีย และข้อแลกเปลี่ยน (Trade-offs) ในการเลือกสถาปัตยกรรม
  • • System Architecture Diagram: การเขียนและวิเคราะห์แผนผังสถาปัตยกรรมระบบสำหรับโปรเจกต์จริง