Main Service

ข้อกำหนดกลางของ SML REST API — header, รูปแบบ response และรหัส error ที่ทุก endpoint ใช้ร่วมกัน

Authorization

ทุก request ต้องแนบ header ต่อไปนี้

Header	ค่า	คำอธิบาย
GUID	smlx	ค่าคงที่สำหรับการเชื่อมต่อ
configFIleName	(string)	ชื่อไฟล์ Server Config
databaseName	(string)	ชื่อฐานข้อมูล
provider	(string)	รหัสผู้ให้บริการ
Content-Type	application/json; charset=utf-8	สำหรับ POST / PATCH

Content-Type และภาษาไทย

request แบบ POST / PATCH ที่มีข้อมูลภาษาไทย (เช่น remark, ชื่อ, หมายเหตุ) ต้องระบุ charset=utf-8 ใน Content-Type เสมอ

Content-Type: application/json; charset=utf-8

หากไม่ระบุ charset ข้อความภาษาไทยอาจถูกบันทึกลงฐานข้อมูลผิดพลาด (เช่น หมายเหตุ เพี้ยนเป็น เธซเธกเธฒเธข) และข้อมูลที่เพี้ยนแล้วต้องบันทึกเอกสารใหม่ — การปรับ header ภายหลังไม่ทำให้ข้อมูลเดิมกลับมาถูกต้อง

Response Format

ทุก response เป็น JSON โดยใช้ฟิลด์ success เป็นตัวบอกผลลัพธ์หลัก

สำเร็จ

{ "success": true, "data": { ... }, "pages": { ... } }

ฟิลด์	คำอธิบาย
success	true
data	ข้อมูลผลลัพธ์ — กรณี POST สร้างเอกสารสำเร็จ data.code คือเลขที่เอกสาร
pages	ข้อมูลแบ่งหน้า มีเฉพาะ response แบบ list เท่านั้น

ผิดพลาด

{ "success": false, "error": true, "message": "...", "code": "99" }

ฟิลด์	คำอธิบาย
success	false
code	รหัสประเภท error (ดูตาราง HTTP Status ด้านล่าง)
message	รายละเอียดสาเหตุที่แท้จริง

code ใน response ผิดพลาดคือ "รหัส error" ส่วน data.code ใน response สำเร็จคือ "เลขที่เอกสาร" — เป็นคนละความหมายกัน

HTTP Status และรหัส Error

ผลลัพธ์	HTTP	code	body
สำเร็จ	200	—	{ "success": true, ... }
ข้อมูล / DB ผิดพลาด	400	99	{ "success": false, ... }
payload ผิดรูปจน parse ไม่ได้ หรือ error ภายใน	500	500	{ "success": false, ... }
เรียก URL / path ที่ไม่มีอยู่	404	—	ข้อความ No such resource
ใช้ HTTP method ไม่ถูกต้อง	405	—	ข้อความ
อ้างอิงเอกสารที่ไม่มีอยู่ (เฉพาะ updateapprovestatus)	404	98	{ "success": false, ... }

รหัส 99 เป็นรหัสรวมของข้อผิดพลาดด้านข้อมูล — สาเหตุที่แท้จริงจะอยู่ในฟิลด์ message เสมอ

กรณี payload ผิดรูป ฟิลด์ message อาจแสดงข้อความ HTTP 400 Bad Request แต่ HTTP status จริงคือ 500 — ให้ยึดตาม HTTP status

กรณีค้นเอกสารไม่พบ

การ GET เอกสารด้วย doc_no ที่ไม่มีอยู่ ไม่ถือเป็น error — จะได้ HTTP 200 โดย data เป็น null

{ "success": true, "data": null }

client ต้องตรวจสอบ data == null เองเพื่อจับกรณีนี้ (ระบบไม่คืน HTTP 404 สำหรับการ GET ที่ไม่พบเอกสาร)

แนวทางตรวจสอบผลลัพธ์ฝั่ง client

1. อ่านฟิลด์ success เป็นตัวตัดสินหลัก
2. เมื่อ success = false — ใช้ HTTP status ระบุประเภทข้อผิดพลาด และอ่าน message เพื่อดูสาเหตุ
3. สำหรับการ GET เอกสารเดี่ยว — ตรวจสอบ data == null เพื่อจับกรณีไม่พบเอกสาร