Network Services — จาก Socket สู่ API

1HTTP Request/Response ในมุมของ Distributed Application

หัวข้อก่อนหน้าออกแบบ protocol เองทั้งหมด (framing, command format) — HTTP คือตัวอย่างของ protocol ที่มีคนออกแบบไว้ให้แล้วและใช้กันทั่วโลก มันแก้ปัญหาเดียวกับที่เจอในหัวข้อที่ 1 ทุกอย่าง เพียงแต่เป็นมาตรฐาน:

2API Contract

Contract ที่ดีทำให้ทีมพัฒนา client และทีมพัฒนา server ทำงานคู่ขนานกันได้โดยไม่ต้องรอกัน — ตราบใดที่ทั้งสองฝั่งยึด contract เดียวกัน ระบบก็ทำงานร่วมกันได้แม้ implementation ภายในจะต่างกันโดยสิ้นเชิง (คนละภาษา คนละทีม)

3REST API

PUT    /keys/course        body: {"value": "NetworkComputing"}   → 200/201
GET    /keys/course                                              → 200 {"value": "NetworkComputing"}
DELETE /keys/course                                               → 204 หรือ 404 ถ้าไม่มี key นี้

HTTP Status Code

4JSON Serialization และ Stateless Service

REST API ส่วนใหญ่ใช้ JSON เป็น body format (เหมือนที่ทำใน NDJSON ของหัวข้อที่ 1) — แต่ HTTP มี Content-Type: application/json ระบุชัดเจนแทนที่ต้องตกลงรูปแบบกันเอง

ทำไม statelessness สำคัญ: ถ้า server ตัวหนึ่งล่ม request ถัดไปจาก client เดิมส่งไป server ตัวอื่นได้ทันทีโดยไม่เสียข้อมูล (สำคัญมากสำหรับ load balancing และ scaling ในหัวข้อถัดไป) — เทียบกับ protocol ใน lab หัวข้อที่ 1 ที่ connection เดียวคุยกันยาวและ server จำ state ของ connection นั้นไว้ (stateful ในระดับ connection)

5Synchronous Communication

Synchronous เข้าใจง่าย debug ง่าย แต่มีข้อเสียสำคัญที่จะเห็นชัดในหัวข้อที่ 3: ถ้า service ที่ถูกเรียกช้าหรือค้าง service ที่เรียกก็ค้างตามไปด้วย (cascading latency/failure)

6Authentication เบื้องต้น

7REST เทียบกับ RPC

8WebSocket และ Message Queue (ภาพรวม)

9Lab: ระบบสองบริการ — Service ที่เป็นทั้ง Server และ Client

สร้างสอง service ที่คุยกันเป็นทอด: Service A (order service) รับ request จาก external client แล้วต้องเรียก Service B (inventory service) เพื่อตรวจสต๊อกก่อนตอบกลับ

External Client → [Service A: /orders]  → [Service B: /inventory/{item}]
                        (server)                    (server)
                        (client เมื่อเรียก B)

# service_a.py
from flask import Flask, request, jsonify
import requests

app = Flask(__name__)
INVENTORY_URL = "http://service-b:5001"   # ดู nc-3 เรื่อง Docker service name

@app.post("/orders")
def create_order():
    body = request.get_json()
    item = body.get("item")

    # Service A เป็น "client" ตอนเรียก Service B
    resp = requests.get(f"{INVENTORY_URL}/inventory/{item}", timeout=3)
    if resp.status_code != 200:
        return jsonify({"error": "inventory check failed"}), 502

    stock = resp.json()["stock"]
    if stock <= 0:
        return jsonify({"error": "out of stock"}), 409

    return jsonify({"order_id": 1, "item": item, "status": "confirmed"}), 201

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

# service_b.py
from flask import Flask, jsonify

app = Flask(__name__)
stock_db = {"laptop": 5, "mouse": 0}

@app.get("/inventory/<item>")
def get_stock(item):
    return jsonify({"item": item, "stock": stock_db.get(item, 0)})

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5001)

10ชุดการทดลอง: จาก HTTP หนึ่งคำขอไปสู่ระบบสองบริการ

การทดลองที่ 1 — อ่าน HTTP แบบไม่ผ่าน Browser

1. เปิด service แล้วใช้ curl -v http://localhost:5000/health แยกบรรทัดที่เป็น request header, response header และ body
2. ใช้ curl -i และ curl -I เปรียบเทียบ แล้วอธิบายว่า HEAD ช่วยตรวจ metadata โดยไม่รับ body ได้อย่างไร
3. ส่ง JSON ด้วยและไม่มี Content-Type: application/json จดความต่าง ห้ามให้ server เดาสุ่มว่าข้อมูลเป็นชนิดใด
4. จับ packet แล้วหา TCP connection เดียวกับ request จากคู่ IP/port จากนั้นเชื่อมสิ่งที่เห็นใน HTTP กับ byte stream จากแล็ปก่อน

curl -v -X POST http://localhost:5000/orders \
  -H "Content-Type: application/json" \
  -H "X-Request-ID: lab-001" \
  -d '{"item":"laptop","quantity":1}'

การทดลองที่ 2 — Contract, Validation และ Status Code

เขียนตาราง contract ก่อนลงมือแก้โค้ด ระบุ field ที่จำเป็น ชนิดข้อมูล ช่วงค่า response และ error ทุกแบบ จากนั้นสร้าง test case อย่างน้อย 10 กรณี รวม body ว่าง JSON เสีย quantity เป็นข้อความ จำนวนติดลบ item ไม่มีอยู่ และ request ซ้ำ

การทดลองที่ 3 — Stateless ไม่ได้แปลว่าไม่มีข้อมูล

1. รัน service สอง instance คนละ port แล้วสลับส่ง request ไปทั้งคู่
2. เก็บ session ไว้ใน memory ของแต่ละ process แล้วสังเกตว่า login “หาย” เมื่อ request ไปอีก instance
3. ย้าย state ที่ต้องแชร์ไปยัง database/cache หรือใช้ token ที่ตรวจสอบได้ทุก instance แล้วทดลองใหม่
4. อธิบายว่า stateless หมายถึงแต่ละ request มีข้อมูลพอให้ประมวลผล ไม่ใช่ระบบไม่เก็บ order หรือ user เลย

การทดลองที่ 4 — Service A เป็นทั้ง Server และ Client

ใช้ตัวอย่าง order/inventory ด้านบน เพิ่ม log เวลาเริ่มและจบการเรียกแต่ละช่วง ทดลอง inventory ตอบใน 50 ms, 1 s และ 5 s วาดเส้นเวลาว่าเวลาของผู้ใช้ถูกใช้ที่ A หรือ B เท่าใด แล้วตั้ง timeout ฝั่ง A เป็น 2 s

การทดลองที่ 5 — Idempotency และคำขอที่ส่งซ้ำ

1. ให้ client ส่ง POST /orders แล้วตัด connection ก่อนอ่าน response จากนั้นส่งซ้ำ นักศึกษาต้องตอบให้ได้ว่าคำสั่งแรกสำเร็จหรือไม่
2. เพิ่ม Idempotency-Key ให้ server เก็บผลลัพธ์ตาม key ถ้าได้ key เดิมให้คืนผลเดิมโดยไม่สร้าง order ใหม่
3. เปรียบเทียบกับ PUT ที่กำหนด resource ID ล่วงหน้า และอธิบายว่า HTTP method ที่ควร idempotent ยังต้องพึ่ง implementation ที่ถูกต้อง

การทดลองที่ 6 — REST, RPC, WebSocket และ Queue เลือกตามงาน

อย่าเลือกจากความทันสมัย ให้เลือกจากรูปแบบการสื่อสาร ทดลองออกแบบงานเดียวกันสี่แบบ: ดู stock, คำนวณราคา, ส่งสถานะสด และส่งอีเมลภายหลัง แล้วกรอกตาราง

ชิ้นงานและเกณฑ์ตรวจ

• OpenAPI หรือ contract ที่สอดคล้องกับโค้ดจริง พร้อมตัวอย่าง success/error
• ชุดทดสอบที่รันซ้ำได้ ไม่ใช่คลิกทดลองด้วยมืออย่างเดียว
• เส้นเวลาของ request ข้ามสอง service พร้อม request ID เดียวกัน
• รายงาน failure อย่างน้อย 5 แบบ ระบุสิ่งที่ผู้ใช้เห็น สิ่งที่ log เห็น และการแก้ที่เลือก
• บันทึกสั้น ๆ ว่าถ้าระบบนี้โตขึ้น จุดใดควรยัง synchronous และจุดใดควรเปลี่ยนเป็น queue

11สรุปและขั้นตอนถัดไป

เราเริ่มจากข้อความ HTTP หนึ่งฉบับ แล้วเห็นว่าเมื่อบริการหนึ่งเรียกอีกบริการ ความช้าและความล้มเหลวจะไหลย้อนกลับมาหาผู้ใช้ ขั้นถัดไปคือทำให้ failure เหล่านี้เกิดซ้ำได้ วัดได้ และ deploy ระบบโดยไม่ต้องหวังว่าทุกส่วนจะทำงานพร้อมกันเสมอ