อ่านโจทย์สอบกลางภาคให้ขาด ก่อนลงมือเขียน

go version go1.26.5 darwin/arm64
github.com/gin-gonic/gin v1.12.0
RFC 9110 (HTTP Semantics)      # อ่านหัวข้อ 9.3.4 PUT ของจริง

1 · โจทย์ทั้ง 9 ข้อ วางเรียงในที่เดียว

สไลด์แบ่งเป็น 4 กลุ่ม ผมเรียงตามนั้นและใส่เลขข้อกำกับไว้ให้อ้างถึงง่าย:

รวมแล้วเป็น endpoint ใหม่ 7 เส้น และเป็นการแก้ของเดิม 2 จุด (ข้อ 7 กับข้อ 9)
ข้อ 7 กับ 9 คือสองข้อที่คนลืมบ่อยที่สุด เพราะมันไม่ได้ขึ้นต้นด้วยคำว่า "สร้าง"

2 · สี่คำในโจทย์ที่เปลี่ยนงานทั้งข้อ

3 · PUT แปลว่า replace — RFC เขียนไว้ตรง ๆ

ไม่ต้องเชื่อผม เปิด RFC 9110 หัวข้อ 9.3.4 อ่านประโยคแรกได้เลย:

The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message content.

แล้ว RFC ยังบอกต่อว่าต้องตอบ status อะไร ซึ่งเป็นจุดที่โจทย์ไม่ได้บอก แต่คนตรวจงานจะดู:

4 · :id ที่รับได้แค่ "me" — ทำไมออกแบบแบบนี้

คำถามแรกที่ควรถามคือ "ถ้ารับได้แค่คำเดียว จะทำเป็น :id ทำไม"
ทำไมไม่เขียน GET /api/v1/users/me ไปตรง ๆ

คำตอบคือ เผื่อวันข้างหน้า — เส้นทาง URL ถูกจองไว้ในรูปแบบที่จะขยายได้ วันที่แอปมีหน้าโปรไฟล์สาธารณะ GET /api/v1/users/<uuid> จะเสียบเข้ามาได้เลย โดยไม่ต้องเปลี่ยน URL ที่ client เก่าเรียกอยู่

ผมลองจดเส้นนี้แล้วยิงสามแบบ:

r.GET("/api/v1/users/:id", func(c *gin.Context) {
	if c.Param("id") != "me" {
		c.JSON(http.StatusForbidden, gin.H{"error": `only "me" is allowed`})
		return
	}
	// ...
})

/api/v1/users/me    -> 200 {"id":"me"}
/api/v1/users/42    -> 403 {"error":"only \"me\" is allowed"}
/api/v1/users/      -> 404 404 page not found

แถวล่างสุดคือของแถมที่ควรรู้: Gin ไม่ยอมให้ :id เป็นค่าว่าง
ต่อท้ายด้วย / เฉย ๆ ไม่เข้า handler เลย ได้ 404 จาก router ตรง ๆ แปลว่าคุณไม่ต้องเขียนโค้ดเช็คว่า id ว่างไหม

5 · Soft delete — แถวไม่ได้หายไปไหน

ตาราง users กับ recipes มีคอลัมน์ deleted_at อยู่แล้ว (ดู บทเรียน 53) และ GORM รู้จักมันเองถ้าตั้งชนิดเป็น gorm.DeletedAt

สิ่งที่ต้องระวังคือ สิ่งที่เกิดขึ้นหลังจากลบ ไม่ใช่ตัวการลบ:

แถวสุดท้ายของตารางคือกับดักที่คนพลาดกันจริง ๆ — ข้อ 2 กับข้อ 7 อยู่คนละหน้าสไลด์ คนละกลุ่มหัวข้อ แต่มันเกี่ยวกันโดยตรง และไม่มีใครบอกคุณ

6 · favorite=true|false — สามสถานะ ไม่ใช่สอง

นี่คือข้อที่ทำให้คนเสียคะแนนมากที่สุด และเสียแบบที่โค้ดไม่ error เลย

ลองไล่ดูว่าผู้ใช้ยิงมาได้กี่แบบ:

สามสถานะ แต่ชนิด bool ของ Go เก็บได้แค่สองค่า
ผมเขียน struct สองแบบวางคู่กันแล้วยิงจริงทั้งสี่แบบ ดูผลเทียบกัน:

type Filter struct {
	Favorite *bool `form:"favorite"`   // ← pointer
}
type FilterPlain struct {
	Favorite bool `form:"favorite"`    // ← ธรรมดา
}

/x                   -> *bool=nil (ไม่ได้ส่งมา)  bool=false  Query()=""       Has=false
/x?favorite=true     -> *bool=true                bool=true   Query()="true"   Has=true
/x?favorite=false    -> *bool=false               bool=false  Query()="false"  Has=true
/x?favorite=         -> *bool=false               bool=false  Query()=""       Has=true

ทางแก้มีสองทาง เลือกทางไหนก็ได้ แต่ต้องตั้งใจเลือก:

7 · averageRating — สไลด์แก้ให้แล้วหนึ่งจุด ยังเหลืออีกหนึ่ง

เทียบสองฉบับบรรทัดต่อบรรทัดในข้อ 9:

Update response ให้ส่ง
average_rating เพิ่มเข้ามาด้วย

Update response ให้ส่ง
averageRating เพิ่มเข้ามาด้วย

เปลี่ยนจาก snake_case เป็น camelCase — ซึ่งตรงกับที่เหลือของ API แล้ว (สังเกตว่าข้อ 4 ก็เขียน imageUrl ไม่ใช่ image_url)

8 · จด route ทั้ง 10 เส้นโดยไม่ให้ Gin panic

หลังทำครบ ระบบจะมี route ที่มี :id อยู่หลายเส้นซ้อนกันบน path เดียวกัน
Gin มีกฎข้อหนึ่งที่ทำให้โปรแกรมตายตั้งแต่ยังไม่ทันรับ request แรก ถ้าคุณตั้งชื่อ parameter ไม่ตรงกัน:

e.GET("/api/v1/recipes/:id", ...)
e.GET("/api/v1/recipes/:recipeId/favorite", ...)   // ชื่อคนละชื่อ

PANIC: ':recipeId' in new path '/api/v1/recipes/:recipeId/favorite'
conflicts with existing wildcard ':id' in existing prefix '/api/v1/recipes/:id'

9 · ตารางสรุป — endpoint กับ status ที่ควรตอบ

ย้ำว่าโจทย์ไม่ได้กำหนด status code ให้ ตารางนี้คือข้อเสนอที่อิง RFC 9110 ไม่ใช่คำสั่งจากสไลด์ ถ้าคุณเลือกต่างจากนี้ ให้เลือกแล้วทำให้เหมือนกันทั้งระบบ

10 · เช็กลิสต์ก่อนส่ง

ทดสอบความเข้าใจ

อ้างอิง

• RFC 9110 §9.3.4 — PUT — อ่านแค่สองย่อหน้าแรก ก็ได้คำตอบเรื่อง "replace ทั้งก้อน" และ status code ที่ต้องตอบ (201 เมื่อสร้างใหม่ · 200/204 เมื่อแก้ของเดิม)
• RFC 9110 §9.3.5 — DELETE — อ่านเพื่อดูว่า RFC ไม่ได้บังคับว่าต้องลบจริง ขอแค่ resource นั้นเลิกให้เข้าถึง — soft delete จึงไม่ผิดมาตรฐาน
• strconv.ParseBool — ตัวที่ Gin เรียกตอน bind bool · ดูรายการค่าที่รับได้ จะเห็นว่า 1 · t · TRUE ผ่านหมด ส่วน yes ไม่ผ่าน
• GORM — Soft Delete — อ่านหัวข้อ Find soft deleted records เพื่อรู้จัก Unscoped() ซึ่งคือทางเดียวที่จะเห็นแถวที่ถูกลบตอน debug
• บทเรียน 53 — ที่มาของคอลัมน์ image_url ซึ่งสไลด์ฉบับ Post เพิ่งเพิ่มเข้ามาเพื่อรองรับข้อ 4 โดยเฉพาะ