Rest api คืออะไร
ตอนทำงานใหม่เมื่อประมาณปี ค.ศ. 2015 (พ.ศ. 2558) ช่วงนั้นนี่วงการ IT นี่กำลังบูมมากมีเรื่อง Start up ที่กำลังมาใหม่ๆ ใครๆก็พากันไปสนใจ ตอนผมกำลังจะจบมีบริษัทใหญ่ๆออกมาหาคนเข้าไปทำงานบริษัท Start up มากมาย หนึ่งในสิ่งที่เขาเอามาขายคือบริษัทเราทำ Rest api ซึ่งก็สร้างความสงสัยให้ผมว่าไอ้ Rest api เนี่ยมันคืออะไรวะ ทำไมต้องเอามาเป็นจุดขายเรียกเด็กจบใหม่ไปทำงานด้วย พอเริ่มทำงานก็เริ่มทำการค้นหาว่าไอ Rest api มันคืออะไร มันดีตรงไหน ซึ่งก็โชคร้ายที่บริษัทที่ผมไปทำงานไม่ได้พัฒนา Application ที่เป็นแบบ Rest api ทำให้ไม่มีคนสอน คราวนี้พอเราไปหาอ่านว่า Rest api ก็เจอข้อมูลมากมาย ซึ่งพาเราหลงไปกับการ Implementation แบบ Search “Rest api” ก็ไปเจอแต่วิธี Implement จนเราหลงว่ามันคือการทำอะไรแบบนั้น จนไป Search เจอคนที่พูดแค่เรื่องทฤษฎีอย่างเดียว
สำหรับใครอยากอ่าน best pracetice สามารถอ่านได้ที่ : https://blog.2my.xyz/2021/01/24/guidelines-best-practices-for-design-restful-api/ เขาเขียนได้ละเอียดมาก แต่สำหรับใครอยากอ่านแบบบ้านๆเล่าเรื่องไปเรื่อยๆก็อ่านต่อด้านล่าง
ยกตัวอย่างเขียน App ร้านขายของ
ถ้าเราเขียน Web application แบบธรรมดาเราจะใช้ HTTP POST ยิง JSON ไป Backend โดย URL ที่ยิงไปก็แล้วแต่จะตั้งกัน
Create Product
URL ( Http method : POST )
1 | /api/create-product |
Request Body
1 | { |
Response Body
1 | { |
Update Product
URL ( Http method : POST )
1 | /api/update-product |
Request Body
1 | { |
Response Body
1 | { |
Delete product
URL ( Http method : POST )
1 | /api/delete-product/{productId} |
Response Body
ไม่มี Body ดูแค่ http status ว่าเป็นตระกูล 200 ไหม
Get product
URL ( Http method : POST )
1 | /api/get-product |
Request Body
1 | { |
Response Body
1 | { |
Search Product
URL ( Http method : POST )
1 | /api/search-product |
Request boyd
1 | { |
Response Body
1 | [ |
เรา Design API ของ Web application เท่านี้ก็สามารถทำงานได้แล้วใช่มะ คราวนี้มันก็ไม่มีแนวทางอะไรกันใช่ไหมครับ ใครอยากจะตั้งชื่ออะไรแบบไหนก็ได้
แต่คราวนี้ถ้าเราสังเกตุดีๆจะเห็นว่า
- ส่วนใหญ่ที่เราสั่งงานกับ Backend เนี่ยส่วนใหญ่มันเป็น Resource นะ ถ้าดูจากตัวอย่างเรายุ่งกับ Product ซึ่งเป็น Resource ของระบบ
- ตัว Http method เนี่ยมันมีอย่างอื่นนอกจาก POST เช่น GET , PUT , PATCH , DELETE ซึ่งจะเห็นว่ามี GET, DELETE อยู่แล้ว ถ้าหา Http method มาให้ CREATE, UPDATE, SEARCH ได้ก็จะครบทุกการกระทำที่ต้องการ
เฮ้ยงั้นเราทำ URL ที่สื่อถึง Resource และจะทำอะไรเกี่ยวกับ Resource ก็ให้ดูผ่าน Http Method ด้วยแนวคิดนี้จึงเกิดตัวแนวทางการสร้าง API แบบใหม่
เปลี่ยนไปเป็น API แบบ REST API
Rest api ก็แค่เพียงการกำหนด API รูปแบบหนึ่งเท่านั้นเอง เรามาลองดูว่าถ้าเปลี่ยนจากแบบเก่าเป็น Rest API จะมีอะไรเปลี่ยนแปลงไปบ้าง
Create Product
URL ( Http method : POST )
1 | /api/products |
Request Body
1 | { |
Response Body
1 | { |
ในส่วนของ Create product จะมีการเปลี่ยนแปลงตรงส่วน URL ให้เป็น /api/products จะเห็นว่าตัว url จะสื่อว่าตอนนี้เรากำลังจะจัดการกับ product
Update Product
URL ( Http method : PUT )
1 | /api/products/{productId} |
Url path
productId คือ productId ของ Product
Request Body
1 | { |
Response Body
1 | { |
สิ่งที่เปลี่ยนไปของการ Update product คือ
- เปลี่ยน URL ไปเป็น /api/products/{productId}
- เปลี่ยนไปใช้ Http method : PUT
จะเห็นว่ามีการกำหนดว่าใน url จะต้องมี productId อยู่ใน url ด้วย ซึ่งพอมาอ่าน url เราจะเข้าใจว่าเรากำลังจะทำอะไรเกี่ยวกับ product ที่มี productId นี้อยู่ ซึ่งถ้าเราบอกว่า PUT คือการ Update ก็จะกลายเป็น เราทำการ Update product ที่มี productId นี้อยู่
Delete product
URL ( Http method : DELETE )
1 | /api/products/{productId} |
Url path
productId คือ productId ของ Product
Response Body
ไม่มี Body ดูแค่ http status ว่าเป็นตระกูล 200 ไหม
สิ่งที่เปลี่ยนไปของการ Delete product คือ
- เปลี่ยน URL ไปเป็น /api/products/{productId}
- เปลี่ยนไปใช้ Http method : DELETE
อันนี้ก็จะคล้ายๆกับ Update เลยแต่เปลี่ยนเป็น Http method เป็น DELETE พอเราอ่าน Http method และ URL เราก็จะเข้าใจว่ามันคือ การ Delete product ที่มี productId นี้
Get product
URL ( Http method : GET )
1 | /api/products/{productId} |
Url path
productId คือ productId ของ Product
Response Body
1 | { |
สิ่งที่เปลี่ยนไปของการ Get product คือเปลี่ยนไปใช้ Http method : GET พอเราอ่านโดยใช้ URL และ Http method รวมกันจะได้เป็น ต้องการดึงข้อมูล Product ที่มี productId นี้
Search Product
URL ( Http method : GET )
1 | /api/products/{productId}?productName={productNameValue}&startPrice={startPriceValue}&stopPrice={stopPriceValue} |
Url path
productId คือ productId ของ Product
Query parameter
- productName = ใช้ Search หา Product ที่มีค่าตรงกับที่ส่งไป
- startPriceValue = ใช้ Search หาค่า Product ที่มีค่า price มากกว่าหรือเท่ากับค่าที่ส่งไป
- stopPriceValue = ใช้ Search หาค่า Product ที่มีค่า price น้อยกว่าหรือเท่ากับค่าที่ส่งไป
Response Body
1 | [ |
สิ่งที่เปลี่ยนไปของการ Search Product คือเปลี่ยนไปใช้ Http method : GET และย้ายพวกเงื่อนไขการค้นหาที่อยู่ใน Request body ย้ายไปอยู่ที่ Query parameter แทน ซึ่งพอเราอ่าน url, http method, query parameter ก็จะเข้าใจว่าต้องการ search ข้อมูล product ตามเงื่อนไขใน Query parameter
มันก็แค่เปลี่ยนรูปแบบการกำหนด API
ใช่ครับทั้งหมดที่กล่าวมาของ Rest api นั้นก็แค่การเปลี่ยนรูปแบบการกำหนด api เท่านั้นเอง โดยผมทำตารางการเปลี่ยนแปลงไว้ด้านล่างลองไปดูครับ
Http method
Action | Old style api | Rest api |
---|---|---|
Get Resource | POST | GET |
Create Resource | POST | POST |
Update Resource | POST | PUT |
Delete Resource | POST | DELETE |
Search Resource | POST | GET |
URL
Action | Old style api | Rest api |
---|---|---|
Get Resource | /api/get-product | /api/products/{productId} |
Create Resource | /api/create-product | /api/products |
Update Resource | /api/update-product | /api/products/{productId} |
Delete Resource | /api/delete-product | /api/products/{productId} |
Search Resource | /api/search-product | /api/products?query-parameter={value} |
ถ้าถามว่าการเปลี่ยนตรงนี้มีผลกระทบอะไรกับ Code ที่เขียนไปแล้วบ้างก็ต้องบอกว่ากระทบแหละครับ แต่มันก็ไม่ได้กระทบอะไรมากเลยมันแค่กระทบตรงส่วนที่เป็น Code ตรง Controller เท่านั้นเอง
ตัวอย่าง Code เปรียบเทียบระหว่าง Get แบบ Old และ Rest Api
1 |
|
ซึ่งจะเห็นว่ามีความแตกต่างอยู่ตรงวิธีที่จะเอาค่า productId มาใช้กับ productService โดยแบบ Rest api นั้นจะเอาค่าจาก URL path ส่วนแบบเก่านั้นจะใช้จาก Request body แทน
สรุป
Rest api ก็คือรูปแบบการกำหนด API รูปแบบหนึ่งโดยจะใช้ Http method และ URL มาใช้ประโยชน์ ซึ่งประโยชน์อย่างหนึ่งที่ผมเห็นจากการลองทำ Rest api คือมันทำให้เข้าใจว่าเรากำลังจะทำอะไรกับ Resource นี้ผ่าน URL ที่เราได้อ่านเลย ข้อดีอีกข้อของการทำ Rest Api คือความสามารถเรื่องทำการ Cache data ผ่าน Http method GET ส่วนมันมหัศจรรย์อะไรไหม โดยส่วนตัวผมไม่เห็นว่ามันจะมหัศจรรย์หรืออะไรขนาดที่จะมาโม้ว่าใช้ Rest api แล้วเราต้องว้าวตามอะไรขนาดนั้น ส่วนมันมีผลกับการเขียนโปรแกรมไหมนั้นในส่วนนี้นั้นไม่แตกต่างกันมากครับ แค่เปลี่ยน Code ตรงส่วน Controller ให้ไปเอาค่าจากพวก Url path, query parameter แทนการดึงค่าจาก Request body
ถ้าใครอ่านมาถึงตรงนี้อาจจะไม่ค่อยว้าวกับ Rest api เหมือนที่ผมไม่ว้าวแหละครับ แต่ๆๆๆๆ จริงๆที่ผมอธิบายมาเนี่ยมันเป็น Rest api ระดับ 2 มันมี Rest api ที่สูงกว่านี้ ซึ่งพออ่านแล้วรู้สึกว่าน่าสนใจมากมันเรียกว่า HATEOAS ถ้าอยากอ่านแบบจริงจังผมแนะนำ Link นี้อธิบายเข้าใจง่ายมาก แถมตลกด้วย
"สิ่งที่ผมเขียนขึ้นเป็นเพียงความรู้และความเข้าใจของบุคคลเพียงบุคคลเดียว ดังนั้นอย่าเพิ่งเชื่อในสิ่งที่ผมเขียนและอธิบาย ลองทำความเข้าใจว่ามันเป็นจริงอย่างนั้นไหมและลองหาแหล่งอ้างอิงอื่นๆว่าเขามีแนวคิดอย่างไร เรื่องการ Design และวิธีการใช้งานไม่มีถูกไม่มีผิดมีแต่เหมาะสมกับงานนั้นไหม"
Ref
- https://blog.2my.xyz/2021/01/24/guidelines-best-practices-for-design-restful-api/
- https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
- https://www.slideshare.net/josdirksen/rest-from-get-to-hateoas
- https://www.slideshare.net/XEmacs/representational-state-transfer-rest-and-hateoas
เพลงประกอบการเขียน Blog
เสียงพี่แอนนี่เหมาะกับเพลงเศร้าจริงๆ
น้องหมูปิ้ง
น้องหมูปิ้งน่ารักมากๆไปติดตามน้องกันได้ที่ : https://www.facebook.com/donteatthismooping/