Cheat sheet
ทุกตารางและสูตรที่ต้องจำสำหรับข้อสอบปลายภาค รวมไว้หน้าเดียว
HTTP Status Codes
| Code | ชื่อ | ใช้เมื่อ |
| 200 | OK | สำเร็จ (GET, PATCH, DELETE) |
| 201 | Created | สร้างทรัพยากรใหม่สำเร็จ (POST) |
| 400 | Bad Request | ข้อมูลจาก client ผิดรูปแบบ / ไม่ครบ / validation ไม่ผ่าน |
| 401 | Unauthorized | ยังไม่ยืนยันตัวตน หรือ token ผิด/หมดอายุ (AuthN) |
| 403 | Forbidden | ยืนยันตัวตนแล้วแต่ไม่มีสิทธิ์ (AuthZ) |
| 404 | Not Found | ไม่มีทรัพยากรนั้น |
| 500 | Internal Server Error | โค้ดฝั่ง server พัง |
HTTP Methods & การอ่านข้อมูล
| Method | ทำอะไร | อ่านข้อมูลจาก |
| GET | Read | req.params (path) / req.query (?) |
| POST | Create | req.body |
| PUT | Update ทั้งชิ้น | req.body |
| PATCH | Update บางฟิลด์ | req.body |
| DELETE | Destroy | req.params |
3 Tiers
Presentation "What the user sees" HTML, CSS, JS, Bootstrap
Logic "What the app does" Node.js, Express
Persistence "What the app remembers" SQLite, JSON files
HTTP lifecycle: DNS → TCP/TLS handshake → request → server processing (middleware) → response → render
สัญลักษณ์ UML
| ไดอะแกรม | ประเภท | องค์ประกอบสำคัญ |
| Use Case | Behavioral | actor (คนแท่ง), use case (วงรี), system boundary (กล่อง), «include» / «extend» |
| Activity | Behavioral | initial node, action, decision (ข้าวหลามตัด), fork/join (แท่งหนา), final node, swimlane |
| Sequence | Behavioral | lifeline (เส้นประ), activation box, message (ลูกศร), fragment alt/opt/loop |
| Component | Structural | provided interface (ลูกบอล), required interface (ซ็อกเก็ต), system boundary cut |
| «include» | «extend» |
| บังคับไหม | ต้องทำเสมอ | ทำเฉพาะบางเงื่อนไข |
| ทิศลูกศร | หลัก → ย่อย | เสริม → หลัก |
| ตัวอย่าง | Checkout include Login | Checkout extend Apply Discount |
Web Storage
| localStorage | sessionStorage | Cookies |
| อยู่นานแค่ไหน | จนกว่าจะลบเอง | ปิดแท็บแล้วหาย | ตามที่ตั้งค่า |
| Scope | ทุกแท็บของ origin | เฉพาะแท็บนั้น | Domain + Path |
| Capacity | ~5–10MB | ~5MB | ~4KB |
| เก็บ token ได้ไหม | ไม่ควร (XSS) | ไม่ควร | ควร ถ้าตั้ง HttpOnly |
โค้ดที่ต้องเขียนได้
// GET ข้อมูลมาแสดง
fetch('/api/products')
.then(res => res.json())
.then(data => renderProducts(data))
.catch(err => showError());
// POST ส่งข้อมูล
fetch('/api/checkout', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(orderData)
});
// Event delegation
parent.addEventListener('click', e => {
const btn = e.target.closest('.add-to-cart');
if (!btn) return;
addToCart(btn.dataset.id);
});
// Debounce 300ms
clearTimeout(timer);
timer = setTimeout(() => filterProducts(value), 300);
// localStorage
localStorage.setItem('cart', JSON.stringify(cart));
const cart = JSON.parse(localStorage.getItem('cart'));
// Express พื้นฐาน
const express = require('express');
const app = express();
app.use(express.json()); // ต้องมาก่อน routes
app.get('/api/products/:id', (req, res) => {
const item = products.find(p => p.id == req.params.id);
if (!item) return res.status(404).json({ error: 'Not found' });
res.status(200).json(item);
});
// JWT
const token = jwt.sign({ id: user.id }, process.env.SECRET, { expiresIn: '1h' });
const payload = jwt.verify(token, process.env.SECRET);
// Parameterized query
db.get('SELECT * FROM users WHERE email = ?', [email], cb);
Security
| Encryption | Hashing |
| ทิศทาง | สองทาง (ถอดได้) | ทางเดียว (ถอดไม่ได้) |
| ความยาวผลลัพธ์ | ผันแปร | คงที่ |
| ใช้กับ | ข้อมูลระหว่างส่ง (TLS) | รหัสผ่าน |
คุณสมบัติ hash 4 ข้อ: one-way · fixed-length · deterministic · avalanche effect
JWT 3 ส่วน: Header . Payload . Signature (payload อ่านได้ ห้ามใส่ความลับ)
Header ส่ง token: Authorization: Bearer <token>
AuthN (คุณคือใคร) → 401 AuthZ (มีสิทธิ์ไหม) → 403
error ตอน login ต้องเป็น "Invalid email or password" เพื่อกัน user enumeration
Database
PK = ไม่ซ้ำ ไม่เป็น NULL
FK = ชี้ไป PK ของอีกตาราง ค่าที่ใส่ต้องมีอยู่จริง
1:N = FK อยู่ฝั่ง "หลาย"
M:N = ต้องมี junction table (PK = คู่ของ FK สองตัว)
ACID: Atomicity (all-or-nothing) · Consistency (ข้อมูลถูกกฎ)
Isolation (ไม่รบกวนกัน) · Durability (commit แล้วอยู่ถาวร)
SQL Injection แก้ด้วย parameterized query: WHERE email = ?
ROLLBACK = ย้อนงานในฐานข้อมูล
Compensating action = ย้อนงานภายนอก เช่น refund
Scaling
| Vertical (scale up) | Horizontal (scale out) |
| ทำอะไร | เพิ่ม CPU/RAM เครื่องเดิม | เพิ่มจำนวนเครื่อง + load balancer |
| เพดาน | มี | แทบไม่มี |
| เงื่อนไข | ไม่ต้องแก้โค้ด | ต้อง stateless |
Monolith : ง่าย เร็วตอนเริ่ม แต่ shared fate และขยายทั้งก้อน
Microservice: แยก deploy แยก DB จำกัดวงความเสียหาย แต่ debug ยาก
Resilience: timeout · retry · circuit breaker · graceful degradation · health check
สูตรตอบอัตนัย 4 ขั้น
- ปัญหาคืออะไร — บอกอาการที่เห็นเป็นประโยคเดียว
- สาเหตุทางเทคนิค — ระบุชั้นที่ผิด (Presentation/Logic/Persistence) และกลไกที่ทำให้เกิด
- ผลกระทบต่อระบบ/ธุรกิจ — เสียเงิน เสียข้อมูล เสียความเชื่อถือ หรือเสี่ยงกฎหมาย
- วิธีแก้เชิงสถาปัตยกรรม — บอกเป็นข้อ ๆ ว่าจะย้าย logic ไปไหน เพิ่ม middleware/constraint อะไร และ status code ที่ควรตอบ
ห้ามตอบคำเดียวหรือเล่าลอย ๆ — guidelines ระบุชัดว่าต้องอธิบายครบ 4 ขั้น
กับดักข้อสอบ
- Validation ฝั่ง client ไม่ใช่ความปลอดภัย — ต้องตรวจซ้ำที่ server เสมอ
- ห้ามเชื่อราคาที่ client ส่งมา — รับแค่ productId + quantity แล้วดึงราคาจริงจาก DB
- express.json() ต้องอยู่ก่อน routes ไม่งั้น req.body เป็น undefined
- 401 vs 403 — ยังไม่ล็อกอิน = 401, ล็อกอินแล้วแต่ไม่มีสิทธิ์ = 403
- ห้ามเก็บ token ใน localStorage ถ้าเลี่ยงได้ เพราะ XSS อ่านได้
- ไม่มีทางถอด hash กลับ — login คือการเทียบ hash กับ hash
- M:N ต้องมี junction table ห้ามยัด id หลายตัวในช่องเดียว
- ROLLBACK ใช้ไม่ได้กับงานภายนอก ต้องใช้ compensating action
- REST ใช้ชื่อ resource ไม่ใช่คำกริยา — /api/products ไม่ใช่ /getProducts
- include ≠ extend — จำทิศลูกศรและความบังคับให้แม่น
- CORS เป็นฟีเจอร์ ไม่ใช่บั๊ก
- Microservices ไม่ได้ดีกว่าเสมอ — แลกด้วยความซับซ้อนและ eventual consistency