Resource & URI Design

ใน REST นั้น resource คือ abstraction หลัก resource คือสิ่งใดก็ตามที่มีค่าพอจะตั้งชื่อและอ้างอิงถึง ไม่ว่าจะเป็น user, article, order หรือ shopping cart การออกแบบ API ส่วนใหญ่ก็คือการตัดสินใจว่า resource ของคุณคืออะไร และ URI ของแต่ละตัวอ่านออกมาเป็นอย่างไร

Resource และความสัมพันธ์ระหว่างกัน

classDiagram
  class User { +id +name +email }
  class Article { +id +title +body +authorId }
  class Comment { +id +body +articleId +authorId }
  User "1" --> "*" Article : writes
  Article "1" --> "*" Comment : has
  User "1" --> "*" Comment : posts

โดเมนเล็ก ๆ: user เขียน article ซึ่งมี comment

แต่ละกล่องจะกลายเป็น collection ที่คุณสามารถอ้างถึงได้ (/users, /articles, /comments) และความสัมพันธ์ระหว่างกันก็เป็นใบ้ให้เห็นว่า URI จะ nest และ link กันอย่างไร

โมดูลนี้ครอบคลุมอะไรบ้าง

Modeling resources — หาคำนามที่เหมาะสมและระดับความละเอียด (granularity) ที่เหมาะสม
URI naming — แนวปฏิบัติที่ทำให้ API คาดเดาได้
Nesting & relationships — เลือกระหว่าง sub-resource กับการ link
Consistency & conventions — รักษาให้ทั้ง API สอดคล้องกัน

ใน REST อะไรคือ abstraction หลักที่คุณออกแบบโดยยึดเป็นศูนย์กลาง? Functions Resources (คำนาม) ตารางใน database Endpoint ที่ตั้งชื่อตามคำกริยา

URL ใดมีกลิ่นของ RPC มากกว่า REST? /articles /articles/42 /getArticleById /articles/42/comments