แสดงการกระทำ (คำกริยา) ใน REST URI

ฉันมีการพิมพ์เพื่อดำเนินการกับเอกสารลูกค้าของฉัน ฉันต้องการการดำเนินการมาตรฐานอื่น ๆ ที่จะดำเนินการเช่นกันเช่นเพิ่มอัปเดตลบ ดังนั้นฉันมีดังต่อไปนี้:

• สำหรับการสร้างลูกค้าใหม่:
  URI = / customer / {id} ให้พิมพ์ = POST, Methodname = CreateCustomer ()
• สำหรับการอัพเดต:
  URI: / customer / {id} ให้พิมพ์ = PUT, method = UpdateCstomer ()
• สำหรับลบลูกค้า:
  URI = / customer / {id} ให้พิมพ์ = DELETE, Methodname = DeleteCustomer ()
• สำหรับมุมมอง:
  URI: / customer / {id} ให้พิมพ์ = GET, method = GetCustomer ()

ตอนนี้ถ้าฉันต้องการพิมพ์เอกสารสำหรับลูกค้ารายนั้นฉันต้องการฟังก์ชั่นการพิมพ์ URI ของฉันอาจมีลักษณะเช่นนี้: / customer / {id}, type = POST, method = PrintCustomer () แต่ฉันได้ใช้ประเภท URI และ POST นั้นสำหรับ CreateCustomer ฉันต้องการให้ URI มีลักษณะดังนี้: / customer / Print / {id}, type = POST, method = PrintCustomer ()

แต่ฉันไม่สามารถมีคำกริยา "พิมพ์" ใน URI ของฉัน วิธีที่ดีที่สุดในการทำเช่นนี้คืออะไร? ฉันคิดถึง / customer / document / {id} เป็น URI ... แต่ฉันจะพบปัญหาเดียวกัน ฉันจะมีการดำเนินการ CRUD ใน "เอกสาร" ดังนั้นฉันหมดสิ่งที่ฉันจะใช้สำหรับ "พิมพ์" อีกครั้ง กรุณาแนะนำ

POSTไม่ได้หมายถึง "สร้าง" แต่หมายถึง "กระบวนการ" คุณสามารถสร้างทรัพยากรใหม่ได้โดยการโพสต์คำขอที่เหมาะสมไปยังทรัพยากรที่มีอยู่ (เช่นโพสต์/customersเพื่อสร้างลูกค้าใหม่) แต่คุณสามารถใช้POSTเพื่อเติมเต็มการกระทำอื่น ๆ ทั้งหมดที่ไม่สอดคล้องกับกระบวนทัศน์ CRUD ที่เรียบร้อย

ในกรณีของการพิมพ์คุณควรพิจารณาการพิมพ์เป็นทรัพยากร คุณกำลังขอให้ระบบสร้าง "งานพิมพ์" ให้คุณ ซึ่งหมายความว่าคุณสามารถมีprints/ทรัพยากรที่ทำหน้าที่เป็นภาชนะสำหรับการพิมพ์ทั้งหมดที่ร้องขอ เมื่อคุณต้องการพิมพ์POSTเอกสารให้กับทรัพยากรนี้ซึ่งมีข้อมูลทั้งหมดเกี่ยวกับงานพิมพ์ที่คุณต้องการสร้างระบุทรัพยากรที่คุณต้องการพิมพ์ด้วยลิงก์ไปยังพวกเขา

ในฐานะที่เป็นเอกสาร JSON อาจมีลักษณะเช่นนี้:

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

เห็นได้ชัดว่าคุณต้องกำหนดค่านี้ให้เกี่ยวข้องกับสิ่งที่คุณต้องการทำ สิ่งสำคัญคือคุณระบุทรัพยากรอื่น ๆ ที่จะพิมพ์โดยระบุ URL ของพวกเขา

ในการตอบสนองต่อการร้องขอคุณสามารถส่งคืน200 OKหรือ204 No-Contentปฏิบัติและปฏิบัติตามขั้นตอนและลืมได้ แต่ถ้าคุณต้องการที่จะเพิ่มความมันคุณจะกลับมา201 Createdและระบุ URL /prints/12345ของงานพิมพ์ที่สร้างขึ้นใหม่เช่น

จากนั้นผู้ใช้สามารถดำเนินการGETบนทรัพยากรเพื่อดูสถานะของงานพิมพ์ของพวกเขา (อยู่ระหว่างดำเนินการในความคืบหน้า ฯลฯ ) DELETEหรือสามารถของานถูกยกเลิกโดยการออก

เมื่อคุณใช้ถ้อยคำใหม่ปัญหาในแง่ของทรัพยากรการออกแบบ RESTful ควรเกิดขึ้นตามธรรมชาติและให้โอกาสคุณในการขยายและปรับปรุงวิธีที่คุณอาจไม่ได้พิจารณาทันที

ฉันทำสิ่งนี้มาก่อน ในการพิมพ์เอกสารฉันแค่ส่งคืนทรัพยากรในรูปแบบ pdf ลูกค้าจะต้องส่งคำขอ GET สำหรับทรัพยากรด้วยแอปพลิเคชันส่วนหัวยอมรับ / pdf

สิ่งนี้ยังหลีกเลี่ยงการสร้าง URI ใหม่สำหรับทรัพยากรชั่วคราวเช่นงานพิมพ์ การใช้ส่วนหัว HTTP เป็นส่วนหนึ่งของ REST และช่วยให้ URI สะอาด

เพียงเพิ่มพารามิเตอร์ใน GET ของ URI ปัจจุบัน

เป็นเรื่องปกติที่จะใช้ URI เพื่อดำเนินการหลายอย่าง

หากคุณกำลังพูดถึงทรัพยากรเดียวกัน แต่เป็นการกระทำที่แตกต่างคุณจะต้องกำหนดเป็นพารามิเตอร์

/ ลูกค้า / {ID}? พิมพ์ = true

จากนั้นที่ที่คุณกำหนดวิธีการ GET ของคุณคุณจะตรวจพบว่ามีพารามิเตอร์การพิมพ์และจัดการกับมันแตกต่างกันอย่างไร

REST ถูกกำหนดด้วยวิธีต่อไปนี้:

• POST - สร้างระเบียนสินทรัพย์หรือทรัพยากร
• PUT - อัปเดตระเบียนสินทรัพย์หรือทรัพยากร
• DELETE - ลบ, บันทึก, สินทรัพย์หรือทรัพยากร

GET ในทางกลับกันมีวัตถุประสงค์เพื่อใช้ในหลายวิธีเนื่องจากโดยทั่วไปจะมีหลายรูปแบบที่แตกต่างกันซึ่งอาจดึงทรัพยากร นั่นเป็นสาเหตุที่คำขอ GET ถูกแสดงเป็นสตริงการสืบค้น หากคุณกำลังทำงานกับทรัพยากรฐานข้อมูลคุณจะได้รับมุมมองผ่านแบบสอบถามอย่างแท้จริง แต่ REST นั้นตั้งใจให้อยู่ในระดับที่สูงขึ้นเพราะมันถูกออกแบบมาเพื่อจัดการกับทรัพยากรประเภทต่างๆ

ข้อมูลจำเพาะของ REST นั้นค่อนข้างคาดคิดมาก่อนแม้ว่า API นั้นเพิ่งจะเริ่มใช้งานอย่างหนัก

หากคุณสนใจที่จะเรียนรู้เพิ่มเติมเกี่ยวกับโปรโตคอล REST ฉันขอแนะนำให้คุณอ่าน " Haters Gonna Hate HATEOAS "

ปรับปรุง:

@ Shauna ชี้ให้เห็นถึงหลุมที่น่าสนใจในการให้เหตุผลของฉัน ไม่มีเป็นความจริงวิธีการที่เหมาะสมและหลายรูปแบบจะถือว่าได้รับการยอมรับ ฉันคิดเกี่ยวกับมันมากกว่านี้และเนื่องจากการใช้งานที่คุณตั้งใจจะเปลี่ยนข้อมูลให้เป็นการนำเสนอที่แตกต่างกันมันสมเหตุสมผลที่จะนิยามการแปลงเป็น MIME-Type ใหม่

ตัวอย่างเช่นคุณสามารถแสดง URI เป็น:

/customer/{id}+print

ที่ซึ่งคุณสามารถตั้งค่าการตอบสนองเนื้อหาประเภทเป็นข้อความ / html + พิมพ์ ด้วยวิธีนี้คุณจะมีตัวเลือกในการกำหนดการแปลงเพิ่มเติมในอนาคต

ตัวอย่างเช่น:

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

ทั้งสองวิธีทุกรูปแบบเป็นที่ยอมรับ การติดตั้งที่คุณตัดสินใจนั้นขึ้นอยู่กับความชอบส่วนบุคคลและความสามารถของเซิร์ฟเวอร์ของคุณ

นอกเหนือจากนี้ให้ฉันอธิบายเพราะดูเหมือนจะมีความสับสน 'คิวรี' พารามิเตอร์แบบสอบถามและ / หรือเนื้อหาชนิดถูกใช้เพื่อระบุวิธีการแปลงทรัพยากร ไม่ใช่วิธีเรียกใช้งานพิมพ์จริง เพื่อเหตุผลด้านความปลอดภัยการเข้าถึงระดับฮาร์ดแวร์จะถูกปล่อยไปยังผู้ใช้ / ลูกค้า / เบราว์เซอร์เสมอ