นี่เป็น URL REST ที่ไม่ถูกต้องหรือไม่

ฉันเพิ่งอ่านเกี่ยวกับ REST URL และเห็นตัวอย่างต่อไปนี้:

/API/ผู้ใช้/GetUser

ทีนี้ถ้ามีการเข้าถึงผ่าน HTTP ด้วยกริยา GET นี่ไม่ใช่ URL ที่ไม่ถูกต้องเพราะมันอธิบายการกระทำ (GET) ใน URL ใช่หรือไม่


rest
person AwkwardCoder    schedule 05.02.2010    source แหล่งที่มา
comment
เป็นที่น่าสังเกตว่า REST เองก็ต้องการให้ URL ระบุทรัพยากรโดยไม่ซ้ำกัน และไม่ควรให้ความหมายเชิงความหมายที่เฉพาะเจาะจงใดๆ ผู้ใช้บริการควรปฏิบัติต่อ URL อย่างทึบแสง และใช้หลักการที่ว่าการเป็นตัวแทนทรัพยากรจะมี URL ไปยังทรัพยากรอื่นเพื่อนำทางบริการ ต้องบอกว่าทั้งหมดนี้มีประโยชน์อย่างปฏิเสธไม่ได้ในฐานะ 'ผู้บริโภค' ของมนุษย์ที่สามารถตีความ URL ของบริการเป็นโครงสร้างแบบลำดับชั้น   -  person Joe    schedule 05.02.2010
comment
@Joe: ฉันคิดว่าคุณพลาดประเด็นของคำถาม ซึ่งวิธีที่ฉันอ่านนั้นเกี่ยวกับคำกริยาและคำนามแทนที่จะเป็นลำดับชั้นในแง่ของระบบไฟล์   -  person    schedule 05.02.2010
comment
@Roger ถูกต้อง ฉันสนใจความคิดเห็นของผู้คนเกี่ยวกับคำกริยาใน url...   -  person AwkwardCoder    schedule 05.02.2010

คำตอบ (5)


arrow_upward
6
arrow_downward

ไม่มีสิ่งที่เรียกว่า REST URL อันที่จริงแล้ว คำว่า REST URL นั้นค่อนข้างจะขัดกับความเป็นจริง ข้อจำกัด ไฮเปอร์มีเดียในฐานะกลไกของสถานะแอปพลิเคชัน รับประกันว่า URL นั้นไม่เกี่ยวข้อง: คุณจะติดตามลิงก์ที่เซิร์ฟเวอร์นำเสนอให้คุณเท่านั้น คุณไม่เคยเห็น อ่าน หรือพิมพ์ URI เลยแม้แต่น้อย (เช่นเดียวกับการท่องเว็บ: คุณไม่ต้องดู URL ของลิงก์ อ่าน จดจำ แล้วพิมพ์ลงในแถบที่อยู่ คุณเพียงแค่คลิกลิงก์นั้นและไม่สนใจว่าจริงๆ แล้วลิงก์จะเขียนว่าอะไร)

คำว่า REST URL แสดงเป็นนัยว่าคุณใส่ใจเกี่ยวกับ URL ของคุณในสถาปัตยกรรม REST ของคุณ อย่างไรก็ตาม หากคุณใส่ใจเกี่ยวกับ URL ของคุณในสถาปัตยกรรม REST คุณจะไม่ได้ RESTful ดังนั้น REST URL จึงเป็นสิ่งที่ตรงกันข้าม

[หมายเหตุ: การออกแบบ URI ที่เหมาะสมมีความสำคัญ มาก สำหรับความเป็น URI ของ URI โดยเฉพาะส่วน I นอกจากนี้ ยังมีสาเหตุ ความสามารถในการใช้งาน ที่ดีมากมายสำหรับ URL ที่ สวยงาม แต่ทั้งสองนี้ไม่มีส่วนเกี่ยวข้องกับ REST เลย]

person Jörg W Mittag    schedule 05.02.2010
comment
@ Jörg - ฉันเข้าใจประเด็นของคุณ แต่ในโลกแห่งความเป็นจริงที่คุณมีนักพัฒนาที่สร้าง RESTful API ที่เข้าถึงผ่าน HTTP ฉันต้องพิจารณาสิ่งนี้เพื่อพยายามเข้าใจความคิดของพวกเขา - person AwkwardCoder; 06.02.2010
comment
URL ที่เหลือเป็นเรื่องไร้สาระและไมโครฟอร์แมตไม่ได้รับการศึกษาอย่างสมบูรณ์ในเรื่องนี้ โหวตเห็นด้วย - person SerialSeb; 08.02.2010
comment
ฉันเข้าใจประเด็นนี้ แต่ดูเหมือนเป็นเรื่องอวดรู้ คุณเข้าใจคำถามที่ซ่อนอยู่ที่ถูกถามอย่างชัดเจน แม้ว่าการใช้ถ้อยคำจะผิดก็ตาม เขาถามว่าเส้นทางที่เขาใช้นั้นฟอร์มไม่ดีหรือไม่ - person Amalgovinus; 19.04.2018
comment
@Amalgovinus: มันไม่สามารถเป็นรูปแบบที่ไม่ดีได้เพราะรูปแบบไม่เกี่ยวข้อง HATEOAS หมายความว่าคุณ ติดตาม ลิงก์ คุณไม่ได้อ่านพวกเขา ดังนั้นจึงไม่มีความเกี่ยวข้องโดยสิ้นเชิงกับลักษณะของ URI - person Jörg W Mittag; 19.04.2018
comment
หากฉันจะสร้าง API เพื่อให้นักพัฒนารายอื่นได้ใช้ HATEOAS ไม่ใช่ปรัชญาที่ฉันจะปฏิบัติตาม - person Amalgovinus; 19.04.2018
comment
@Amalgovinus: HATEOAS ไม่ใช่ปรัชญา เป็นหนึ่งในข้อจำกัดที่กำหนดโดย ReST (และข้อจำกัดที่สำคัญที่สุดประการหนึ่ง) คำถามที่ ชัดเจน เป็นเรื่องเกี่ยวกับ ReST โดย OP กล่าวถึง ReST สองครั้งในส่วนเนื้อหา ครั้งหนึ่งอยู่ในชื่อเรื่อง และได้ติดแท็กคำถามด้วย พักผ่อน. ฉันไม่เห็นว่าการเพิกเฉย ReST โดยสิ้นเชิงในคำถามเกี่ยวกับ ReST เพียงอย่างเดียวจะช่วย OP ได้อย่างไร มีสไตล์สถาปัตยกรรมอื่นๆ สำหรับสถาปัตยกรรมระบบสารสนเทศ และ Roy Fielding เองก็ได้ชี้ให้เห็นครั้งแล้วครั้งเล่าว่า ReST นั้นไม่สมเหตุสมผลเลย เว้นแต่คุณจะออกแบบบางสิ่งที่ครอบคลุม ... - person Jörg W Mittag; 19.04.2018
comment
… หลายองค์กรและหลายรุ่น แต่นั่นไม่เกี่ยวข้อง OP ไม่ได้ถามเกี่ยวกับรูปแบบสถาปัตยกรรมอื่นๆ เขาถามเกี่ยวกับ ReST ดังนั้นคำตอบจึงเกี่ยวกับ ReST - person Jörg W Mittag; 19.04.2018

arrow_upward
9
arrow_downward

มันเป็นธรรมเนียมมากกว่ากฎตายตัว แต่ฉันอยากเห็นบางอย่างเช่น /API/User/7123 GET/POST/etc อธิบายกริยาการกระทำ ดังนั้นการใส่ไว้ใน url จะทำให้ซ้ำซ้อน และในสถานการณ์เช่นนี้ก็ไม่มีเหตุผลที่จะไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่ได้รับการพิสูจน์แล้ว

มีสิ่งดีๆ บางส่วน: ทำความเข้าใจ REST: คำกริยา รหัสข้อผิดพลาด และการตรวจสอบสิทธิ์

person adamJLev    schedule 05.02.2010
comment
@SLott แล้ว /Dictionary/English/Kick จะดึงคำจำกัดความของคำว่า Kick ล่ะ? - person Darrel Miller; 05.02.2010
comment
@Darrel Miller: Token Kick ไม่ได้ถูกใช้เป็นคำกริยา; มันถูกใช้เป็นสตริงของกราฟเพื่อระบุคำเฉพาะ ไม่ใช่คำกริยาเพราะถูกใช้เป็นคำสั่งว่าต้องทำอะไร มันเป็นเพียงตัวละคร - person S.Lott; 06.02.2010
comment
@S.Lott ใน URI ของอินเทอร์เฟซ REST ควรจะทึบแสงสำหรับไคลเอ็นต์ ดังนั้นทั้งหมดจึงเป็นเพียงอักขระ ปัญหาคือเรามีสถานการณ์ลัทธิการขนส่งสินค้าที่ทุกคนดูเหมือนจะรู้ว่าไม่ควรมีคำกริยาใน URI แต่มีน้อยคนที่รู้ว่าทำไม - person Darrel Miller; 06.02.2010
comment
เมื่อผู้คนใส่คำกริยาใน URL ก็อาจมีผลข้างเคียงด้านลบอยู่บ้าง ประการแรก อาจทำให้ผู้ใช้อินเทอร์เฟซสับสนได้มาก โดยเฉพาะอย่างยิ่งเมื่อพฤติกรรมของกริยา HTTP และกริยาใน URI ขัดแย้งกัน ประการที่สอง อาจทำให้ผู้คนละเมิดพฤติกรรมที่คาดหวังของกริยา HTTP ตัวอย่างคลาสสิกของการดำเนินการนี้คือการใช้การดำเนินการ 'GET /myresource/delete' อย่างไรก็ตาม หากคุณดูตัวอย่างหลายๆ ตัวอย่าง คุณจะเห็นบางอย่างเช่น 'GET /myresource/edit' สิ่งนี้อาจจะถูกต้องสมบูรณ์ แต่ก็อาจจะไม่ อย่างไรก็ตาม คุณไม่สามารถพูดได้ว่ามันละเมิด REST เนื่องจากมีคำกริยาใน URL - person Darrel Miller; 08.02.2010
comment
@S.Lott ไม่ นั่นไม่ใช่สิ่งที่ฉันกำลังพูดอย่างแน่นอน แต่เห็นได้ชัดว่าเราสื่อสารได้ไม่ดีนักในสื่อนี้ ดังนั้นเรายอมแพ้ก่อนที่กระทู้นี้จะแย่ลงไปกว่านี้ - person Darrel Miller; 08.02.2010
comment
@S.Lott กริยาสามารถเป็นส่วนหนึ่งของ URL ได้ตราบใดที่ไม่มีการละเมิดอินเทอร์เฟซแบบเดียวกัน การมีคำกริยาใน URL ถือเป็นกลิ่นที่บ่งบอกว่าอินเทอร์เฟซแบบเดียวกันอาจถูกละเมิด แต่คุณไม่สามารถบอกได้เพียงแค่ดูที่ URL โดยส่วนตัวแล้วฉันจะไม่ใส่คำกริยาใน url แต่นั่นเป็นเพียงความชอบของฉัน - person Darrel Miller; 08.02.2010
comment
ฉันคิดว่าสิ่งที่ดาร์เรลพยายามจะพูดคือการที่ผู้คนปฏิบัติตามกฎโดยไม่รู้ว่าทำไม รวมถึงแบบแผน RESTy URI ด้วย ฉันเห็นด้วย ผู้คนควรใช้เวลาสักครู่เพื่อทำความเข้าใจ/ค้นหาว่าทำไมเราจึงปฏิบัติตามอนุสัญญาเหล่านี้ ก็มีเหตุผล - person adamJLev; 08.02.2010
comment
@S.Lott ฉันคิดว่าคุณรู้อย่างแน่นอนว่าฉันพูดอะไร แต่คุณพยายามเป็นคนสุดท้ายที่แสดงความคิดเห็นในกระทู้และต้องการให้ความคิดเห็นสุดท้ายใส่คำในปากของฉันที่อนุมานว่าฉันเห็นด้วยกับข้อความดั้งเดิมของคุณ แน่นอนว่าคุณมีสิ่งที่ดีกว่าให้ทำ - person Darrel Miller; 08.02.2010
comment
@Darrel Miller: ฉันเป็นสถาปนิกบริการเว็บ ฉันกำลังพยายามทำความเข้าใจสถาปัตยกรรมบริการเว็บ ฉันกำลังพยายามเข้าใจประเด็นของคุณ ฉันกำลังพยายามหาคำตอบว่าใช่หรือไม่ใช่จากความคิดเห็นของคุณเกี่ยวกับคำกริยาใน URL หากความคิดเห็นของคุณคือ "ใช่" ฉันกำลังพยายามหาเหตุผลที่แน่ชัดว่า "ใช่" โดยไม่มีตัวอย่างที่เจาะจงหรือมีกลิ่นโค้ด อย่างไรก็ตาม จากความคิดเห็นล่าสุดของคุณ ดูเหมือนว่าฉันควรหยุดพยายามทำความเข้าใจประเด็นของคุณอย่างถ่องแท้ และยึดติดกับความไม่เข้าใจอย่างผิวเผิน ฉันแค่อยากจะเข้าใจประเด็นของคุณ - person S.Lott; 08.02.2010

arrow_upward
5
arrow_downward

วิธีที่ดีกว่าคือการมี /API/User/7123 และใช้วิธี GET/POST เพื่อแสดงถึงการดำเนินการ

person epitka    schedule 05.02.2010

arrow_upward
3
arrow_downward

สิ่งนี้ไม่ได้แย่เสมอไป... มันเกี่ยวข้องกับเฟรมเวิร์กที่คุณใช้ในการสร้าง URL ที่เหลือมากกว่า ลิงก์ @Infinity ที่โพสต์ไว้เป็นแหล่งข้อมูลที่ดี แต่อย่าจำกัดตัวเองอยู่เพียงทฤษฎีที่ตั้งไว้ เนื่องจากอาจทำให้เกิดงานมากเกินไปในกรอบงานบางอย่างได้

ตัวอย่างเช่น ไม่มีเหตุผลว่าทำไมคุณถึงไม่ต้องการเรียกใช้ GET บน /API/Users/{id}/Delete เพื่อแสดงข้อความประเภท "คุณแน่ใจหรือไม่" ก่อนที่จะใช้เมธอด DELETE

person Nick Larsen    schedule 05.02.2010

arrow_upward
1
arrow_downward

/API/User/GetUser ไม่สงบ การใช้คำกริยาเพื่อระบุทรัพยากรไม่ใช่เรื่องดี URL ตัวอย่างยังคงใช้ได้ แต่ก็ไม่ได้ทำให้ถูกต้องเช่นกัน มันผิดเหมือนประกาศต่อไปนี้

String phoneNumber = "[email protected]";
person Abrsh    schedule 26.08.2012