นอนนึกเรื่อง REST architecture ว่า เท่าที่เห็นคนจะนึกถึง REST ในแง่ของ Resource URL แต่ไม่ค่อยพูดถึง HATEOAS ซึ่งเป็นอีก principle สำคัญของ REST เหมือนกัน โดยเฉพาะความหมายของ concept Application State ซึ่งถ้าเข้าใจมุมมองเรื่องนี้แล้ว จะเห็นภาพรวมของ REST architecture ได้ไม่ยาก (เพราะส่วนอื่นๆจะเหลือเพียง network infrastructure และ Resource URL ที่เอื้ออำนวยต่อการ cache)

แต่พอมานึกว่าเราจะพัฒนาโปรแกรมให้เป็น REST ได้อย่างไร โดยเฉพาะอย่างยิ่ง ลักษณะของ software architecture เป็นอย่างไร ในเมื่อ REST เองสร้างอยู่บน model ของ Client/Server (= 2 Tiers!)

โดยเทคนิคแล้ว Web infrastructure วางบนพื้นฐานของ REST

แต่นี่เป็นมุมของ physical relationship ถ้าเป็น logical relationship ล่ะ หน้าตาของ software architecture ที่เป็น REST ควรเป็นอย่างไร? และด้วย application ที่สร้างอยู่ MVC pattern ด้วยแล้ว... ในมุมของ Web application น่าจะออกมาในลักษณะนี้

Server-side script

เป็นลักษณะของ Web app arch ที่เขียนด้วย Server-side script (แบบเวปยุคเก่า) สำหรับเวปยุคใหม่ที่นิยมเอา controller มาไว้ฝั่ง browser ด้วย (เช่น AngularJS) ก็จะเป็น

Client-side script

ดูแล้วไม่มีอะไรแปลกเลย มันเป็น arch ที่ชาวบ้านก็ใช้กันมานานนม แปลว่าทุก web app ที่ทำมา ถ้า URL เป็นแบบ resource ก็ถือว่าเป็น REST หมดแล้วสิ?

Hypertext As The Engine Of Application State

เปล่าเลย มีอีก constraint หนึ่งที่ sw arch จะต้อง follow ด้วย ถึงจะเรียกได้ว่าเป็น REST จริงๆ นั่นคือ HATEOAS

HATEOAS model

ประกอบไปด้วยหลักการที่สำคัญคือ

  • Application จะต้อง drive ผ่าน Hyperlink (= URL + Method)
  • Intelligent View: เป็น generic view ที่ไม่มีความรู้ใดๆเกี่ยวกับ application เลย

OpenERP Web Application เป็นตัวอย่างที่ดีของที่ implement บนหลักการนี้ หน้า view ทั้งหลายนั้นถูก generate จาก View XML ของแต่ละ module เอง และ Application state เองก็ถูก drive โดย hyperlink ที่ generated จาก View XML+Model ด้วยเช่นกัน