REST Web Service เนื้อคู่ที่แท้จริงของ Mobile App

ก่อนอื่นต้องทำความรู้จักกับ REST web service กันก่อนว่ามันคืออะไร หลายคนเข้าใจว่าการที่ เปลี่ยนจาก SOAP ที่ encode ด้วย XML มาเป็น JSON encoding ก็คือเป็น REST web service แล้ว ความจริงแล้วความแตกต่างระหว่าง SOAP และ REST ไม่อยู่ที่ encoding แต่เป็นวิธีคิดและออกแบบ คำสั่งใน web service ต่างหาก

จาก “คำกิริยา” เป็น “คำนาม”

โดยทั่วไปถ้าไม่คิดอะไรมาก ถ้าจะออกแบบ web service สำหรับจัดการข้อมูลหนังสือ URL ที่ได้ก็จะออกมาประมาณนี้

/GetBook
/SearchBooks
/DeleteBook
/UpdateBookInfo

สังเกตุว่าจะใช้คำกิริยาและคำนามคู่กันในทุก ๆ service แต่สำหรับ REST web service จะใช้แค่คำนาม เช่น

/books/{bookid}

ถ้าจะจัดการ collection ของหนังสือหลายเล่ม ก็ใช้ URL /books หรือถ้าจะจัดการข้อมูลหนังสือเป็นเล่ม ๆ ก็ใช้ URL /books/{bookid} เป็นการใช้ directory ของ URL ให้เป็นประโยชน์ และยังเป็นมาตรฐานที่ทุกคนเข้าใจได้ง่าย

การเข้าถึงข้อมูลย่อยก็ยังสามารถใช้ directory เข้าช่วยได้อีกด้วยเช่น

/books/{bookid}/name

ลองนึกภาพถ้าเรามีข้อมูลจำนวน หลาย ๆ collection เช่น หนังสือ, ผู้แต่ง, ร้าน, พนักงานขาย, สต๊อก, อื่น ๆ การออกแบบโดยใช้ REST จะช่วยลดจำนวนเส้น webservice ได้มากขนาดไหน

แล้วกิริยาไปอยู่ไหน
—
จากหัวข้อด้านบนเราตัดกิริยาไปจาก URL แล้วใช้ประโยชน์จาก directory เข้ามาช่วยแล้ว เราสามารถเข้าถึงข้อมูลตัวไหนได้แล้ว แต่เราจะบอก web service ยังไงว่าจะสั่งมันทำอะไร คำตอบอยู่ที่ http method ครับ

การเข้าถึงข้อมูลที่เราใช้มี 4 แบบก็คือ create, read, upddate, delete ก็ใช้ http method 4 ตัวตรง ๆ ทื่อ ๆ ซื่อ ๆ ตามตารางเลยครับ

>
| คำสั่ง | HTTP Method | ตัวอย่าง |
|:——:|:———–:|:——————————|
| Create | POST | POST /books |
| Read | GET | GET /books หรือ GET /books/123 |
| Update | PUT | PUT /books/123 |
| Delete | DELETE | DELETE /books/123 |

การตอบผลลัพธ์ (Return result)

นอกจากจะใช้ http mothod ในการเรียก แล้วผลของการทำงาน REST ยังใช้ http response code ให้เป็นประโยชน์อีกด้วย นอกจากมาตรฐานเข้าใจกันทุก service แล้วยังเป็นการตรวจจับ return code ต่าง ๆ ได้ง่ายด้วยโดยเฉพาะพวก error message ต่าง ๆ return code มีให้เลือกมากมายตามมาตรฐาน http แต่ผมคัดตัวที่ใช้บ่อย ๆ มาให้ดูครับ
| Response Code | Description |
|:—————-|:—————————————-|
| 200 OK | The request is OK |
| 201 Created | New resource is created ตอบกลับตอนสร้างด้วย method POST เสร็จ |
| 204 No Content | ข้อมูลว่าง |
| 206 Partial Content | ตอบข้อมูลบางส่วนเช่น กรณีที่จำนวนข้อมูลเกินกว่าที่ตั้งไว้สูงสุด |
|304 Not Modified | กรณีที่ request header ใส่ Last-Modified มาแล้วข้อมูลไม่มีการเปลี่ยนแปลง |
|400 Bad Request | request ผิด format |
|401 Unauthorized | ไม่มีสิทธิ์เข้าถึงข้อมูล |
|404 Not Found | ไม่มี object ตามที่ระบุใน URL |

ไอ้เหลือ (REST) กับ ชายสบู่ (SOAP)

รู้จักกับ REST web service กันแล้วคราวนี้มาเปรียบเทียบระหว่าง ไอ้เหลือ (REST) กับ ชายสบู่ (SOAP) ว่าใครจะเหมาะเป็นคู่แท้สำหรับ mobile app กัน

1. ความอิสระ Mobile app ต้องการความคล่องตัวสูง เพราะ update กันบ่อย บางตัว 2 อาทิตย์ก็มี version ใหม่ออกแล้ว web service ก็มีแนวโน้มจะต้องปรับเพิ่ม กันบ่อย ๆ แต่คุณชายสบู่ เค้ามากับระเบียบแบบแผนที่เรียกว่า Web Service Definition Language (WSDL) ที่เวลาเปลี่ยนทีกระทบกันไปหมด ต่างจาก ไอ้เหลือที่ไม่มีการตั้งกฎเกณฑ์ ยกนี้ต้องให้ใจไอ้เหลือไป
2. ความประหยัด Mobile app ส่วนใหญ่จะรันอยู่บนเครือข่ายมือถือซึ่งใช้มากจ่ายมาก หรือไม่ใช้มากโดนจำกัดความเร็ว การประหยัดก็เลยจำเป็นอย่างยิ่ง ไอ้เหลือใช้ JSON ส่วน ชายสบู่ส่วนมากใช้ XML ถ้าเปรียบเทียบแค่นี้ไอ้เหลือชนะนิดหน่อย แต่ถ้าเปรียบเทียบความสามารถในการ cache ไอ้เหลือสามารถ cache ข้อมูลที่เคย download มาแล้วได้ไม่ต้อง download ใหม่ทั้งชุด ด้วยการใส่ Last-Modified ไว้ใน request header แถม mobile operation ยัง cache ได้อีกด้วยเป็นการ offload server ไม่ให้ทำงานหนักเกินไป ยกนี้ไอ้เหลือก็ชนะคุณชายสบู่อีกยก
3. ความเข้ากันได้ SDK ของ mobile ทั้ง iOS และ Android มันติด REST มาแล้วในตัว การเรียกใช้งานมันก็เลยช่างง่ายแสนง่าย ยกนี้ตัดสินแล้วว่าไอ้เหลือเป็นฝ่ายชนะคะแนนไปขาดลอย…. เย้ ๆ ๆ

สรุป

ไม่รู้จะดีใจที่ ไอ้เหลือชนะไปทำไมในเมื่อใคร ๆ ก็ใช้กัน แต่ที่เขียนทั้งหมดนี้ต้องการให้ใช้ให้ถูกจะได้ ได้ประโยชน์จาก REST อย่างที่มันควรเป็น ไม่ใช่แค่ encode JSON แต่ยังใช้แค่ GET method อย่างเดียว ก็ไม่ต่างจากการใช้ SOAP เพี่ยงแต่ไม่มี WSDL เท่านั้นเอง

*ขอพลังจงสถิดอยู่กับท่าน……..*