Appearance
02.06 ภาพรวมบริการ API (API Overview)
📌 At a Glance
| รายการ | รายละเอียด |
|---|---|
| Topic | API Overview |
| Difficulty | ⭐ Beginner |
| Reading Time | 10 นาที |
| Target | Developer, System Integrator |
| API Version | V1.1 |
⏱ Reading Time
ประมาณ 10 นาที
🎯 Learning Objectives
หลังจากศึกษาหัวข้อนี้แล้ว ผู้อ่านจะสามารถ
- เข้าใจโครงสร้างของ SISAHYGO API V1.1
- เข้าใจการแบ่งกลุ่ม API
- เข้าใจวัตถุประสงค์ของแต่ละ Endpoint
- เตรียมความพร้อมก่อนศึกษา API Specification
Overview
SISAHYGO Integration Platform เปิดให้บริการผ่านมาตรฐาน REST API โดยใช้ HTTPS และ JSON เป็นรูปแบบการสื่อสารหลัก
API ทุก Endpoint ถูกออกแบบให้มีรูปแบบการใช้งานที่สอดคล้องกัน ทั้งในด้าน Authentication, Request Format, Response Format และ Error Handling เพื่อให้นักพัฒนาสามารถเรียนรู้เพียงครั้งเดียวและนำไปใช้ได้กับทุกบริการของระบบ
Business Value
การออกแบบ API ในรูปแบบมาตรฐานช่วยให้
- ลดเวลาในการพัฒนา Integration
- ลดความซับซ้อนของการเรียนรู้ API
- รองรับการเพิ่ม Endpoint ใหม่ในอนาคต
- ทำให้การบำรุงรักษาระบบง่ายขึ้น
Figure 2-6 API Service Landscape
(แทรกรูป Figure 2-6 : API Service Landscape)
Figure 2-6 แสดงภาพรวมของบริการทั้งหมดใน SISAHYGO API V1.1 โดยแบ่งออกเป็น 3 กลุ่มหลัก ได้แก่ Master Data APIs, Transaction APIs และ Tracking APIs ซึ่งครอบคลุมการทำงานตั้งแต่การเตรียมข้อมูล การส่งข้อมูลธุรกรรม ไปจนถึงการติดตามผลการดำเนินงาน
API Categories
SISAHYGO API V1.1 แบ่งออกเป็น 3 กลุ่มหลัก
1. Master Data APIs
ใช้สำหรับ Synchronize ข้อมูลอ้างอิง
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /products | รายการสินค้า |
| GET | /receivers | รายชื่อผู้รับ |
Master Data ควร Synchronize ก่อนเริ่มส่ง Transaction
2. Transaction APIs
ใช้สำหรับส่งข้อมูลเข้าสู่ระบบ
| Method | Endpoint | Purpose |
|---|---|---|
| POST | /order-checkings | สร้างรายการตรวจรับสินค้า |
Transaction API เป็นจุดเริ่มต้นของ Business Workflow
3. Tracking APIs
ใช้สำหรับติดตามผลการดำเนินงาน
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /shipments | ติดตามสถานะการจัดส่ง |
| GET | /order-rejections | ตรวจสอบรายการที่ถูก Reject |
Tracking API ไม่มีผลต่อข้อมูลต้นทางของ Client System แต่ใช้สำหรับแสดงผลและติดตามสถานะ
API Lifecycle
Developer จะใช้งาน API ตามลำดับดังนี้
Authentication
↓
Master Data
↓
Transaction
↓
Trackingการเรียก API ตามลำดับนี้ช่วยลด Validation Error และทำให้ข้อมูลมีความสอดคล้องกันทั้งสองระบบ
API Usage Matrix
| API | Initial Setup | Daily Operation | Monitoring |
|---|---|---|---|
| GET /products | ✅ | 🔄 | - |
| GET /receivers | ✅ | 🔄 | - |
| POST /order-checkings | - | ✅ | - |
| GET /shipments | - | ✅ | ✅ |
| GET /order-rejections | - | เมื่อเกิด Reject | ✅ |
หมายเหตุ: 🔄 หมายถึงควร Synchronize เป็นระยะ เช่น วันละครั้ง หรือเมื่อมีการเปลี่ยนแปลงข้อมูล Master Data
Business Scenario
บริษัท ABC เริ่มใช้งาน SISAHYGO
วันแรก
- ขอ API Key
- Synchronize Products
- Synchronize Receivers
วันทำงานปกติ
- ส่ง Order Checking
- ติดตาม Shipment
- ตรวจสอบรายการ Reject (หากมี)
Workflow นี้สามารถนำไปใช้เป็นมาตรฐานสำหรับทุก Client System ที่เชื่อมต่อกับ SISAHYGO
IMPORTANT
API V1.1 ถูกออกแบบให้ครอบคลุมเฉพาะกระบวนการเชื่อมต่อระหว่าง Client System กับ SISAHYGO
Business Logic ภายใน เช่น
- การออกใบรับส่งสินค้า
- การจัดเที่ยวรถ
- การจัดเส้นทาง
- การคิดค่าขนส่ง
ดำเนินการภายใน SISAHYGO ทั้งหมด และไม่เปิดให้เรียกใช้งานผ่าน API
Key Concepts
| คำศัพท์ | ความหมาย |
|---|---|
| Master Data API | API สำหรับข้อมูลอ้างอิง |
| Transaction API | API สำหรับส่งข้อมูลธุรกรรม |
| Tracking API | API สำหรับติดตามสถานะ |
| REST API | มาตรฐานการสื่อสารผ่าน HTTP |
| JSON | รูปแบบข้อมูลที่ใช้แลกเปลี่ยน |
Best Practices
| Recommendation | Reason |
|---|---|
| เรียก Master Data ก่อน Transaction | ลด Validation Error |
| ใช้ HTTPS ทุกครั้ง | เพิ่มความปลอดภัย |
| เก็บ API Key เป็นความลับ | ป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต |
| ใช้ Tracking API แทนการสอบถาม Manual | ลดภาระการประสานงาน |
Summary
SISAHYGO API V1.1 ถูกออกแบบให้ใช้งานง่าย โดยแบ่ง API ออกเป็น 3 กลุ่มหลัก ได้แก่ Master Data, Transaction และ Tracking ทำให้นักพัฒนาสามารถเข้าใจลำดับการใช้งานได้อย่างรวดเร็ว และรองรับการเชื่อมต่อกับระบบของลูกค้าได้อย่างเป็นมาตรฐาน
Ready for Next Chapter
- [ ] เข้าใจโครงสร้าง API V1.1
- [ ] เข้าใจการแบ่งกลุ่ม API
- [ ] เข้าใจลำดับการเรียก API
- [ ] พร้อมศึกษามาตรฐานการออกแบบ API
References
- REST API Design Best Practices
- JSON RFC 8259
- HTTP RFC 9110
Related Chapters
- Chapter 3 API Standards
- Chapter 4 Authentication
- Chapter 5 Master Data APIs
Next Step
➡️ 02.07 Data Flow