ออกแบบ / เข้าสู่ระบบหรือ / ลงทะเบียนทรัพยากรอย่างจริงจัง?

ฉันกำลังออกแบบเว็บแอปจากนั้นก็หยุดคิดว่าควรจะออกแบบ api ของฉันให้เป็นบริการเว็บที่น่าสนใจ สำหรับตอนนี้ URI ส่วนใหญ่ของฉันเป็นแบบทั่วไปและอาจใช้กับเว็บแอปต่างๆ:

GET  /logout   // destroys session and redirects to /
GET  /login    // gets the webpage that has the login form
POST /login    // authenticates credentials against database and either redirects home with a new session or redirects back to /login
GET  /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx
GET  /user/xxx // gets and renders current user data in a profile view
POST /user/xxx // updates new information about user

ฉันรู้สึกว่าฉันทำอะไรผิดมากที่นี่หลังจากจิ้ม SO และ google

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

เกี่ยวกับอะไร/loginและ/register. ฉันสามารถเปลี่ยน/registerเป็นได้/registrationแต่นั่นไม่ได้เปลี่ยนแปลงวิธีการทำงานพื้นฐานของบริการของฉันหากมีปัญหาที่ลึกซึ้งกว่านั้น

ฉันสังเกตว่าตอนนี้ฉันไม่เคยเปิดเผย/userทรัพยากร บางทีอาจจะใช้ประโยชน์ได้ ตัวอย่างเช่นรับผู้ใช้myUser:

foo.com/user/myUser

หรือ

foo.com/user

ผู้ใช้ปลายทางไม่ต้องการคำฟุ่มเฟือยเพิ่มเติมใน URI อย่างไรก็ตามอันไหนดึงดูดสายตามากกว่ากัน?

ฉันสังเกตเห็นคำถามอื่น ๆ เกี่ยวกับ SO เกี่ยวกับธุรกิจ REST นี้ แต่ฉันอยากจะขอบคุณคำแนะนำบางอย่างเกี่ยวกับสิ่งที่ฉันได้ระบุไว้ที่นี่ถ้าเป็นไปได้

ขอบคุณ!

UPDATE:

ฉันต้องการความคิดเห็นเกี่ยวกับ:

/user/1

VS

/user/myUserName

สิ่งหนึ่งที่โดดเด่นโดยเฉพาะอย่างยิ่งไม่ใช่ REST-ful: การใช้คำขอ GET เพื่อออกจากระบบ

(จากhttp://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods )

วิธีการบางอย่าง (เช่น HEAD, GET, OPTIONS และ TRACE) ถูกกำหนดให้ปลอดภัยซึ่งหมายความว่ามีไว้สำหรับการดึงข้อมูลเท่านั้นและไม่ควรเปลี่ยนสถานะของเซิร์ฟเวอร์ กล่าวอีกนัยหนึ่งก็คือไม่ควรมีผลข้างเคียงนอกเหนือจากผลกระทบที่ไม่เป็นอันตรายเช่นการบันทึกการแคชการแสดงโฆษณาแบนเนอร์หรือการเพิ่มตัวนับเว็บ [ ... ]

[... H] andling [ของคำขอ GET] โดยเซิร์ฟเวอร์ไม่มีข้อ จำกัด ทางเทคนิค แต่อย่างใด ดังนั้นการเขียนโปรแกรมโดยไม่ระมัดระวังหรือโดยเจตนาอาจทำให้เกิดการเปลี่ยนแปลงที่ไม่สำคัญบนเซิร์ฟเวอร์ ไม่ควรทำเช่นนี้เนื่องจากอาจทำให้เกิดปัญหากับการแคชเว็บเครื่องมือค้นหาและตัวแทนอัตโนมัติอื่น ๆ [... ]

สำหรับการออกจากระบบและเปลี่ยนเส้นทางคุณอาจมีโพสต์ใน URI การออกจากระบบของคุณโดยให้การตอบกลับ 303 ที่เปลี่ยนเส้นทางไปยังหน้าหลังการออกจากระบบ

http://en.wikipedia.org/wiki/Post/Redirect/Get

http://en.wikipedia.org/wiki/HTTP_303

แก้ไขเพื่อแก้ไขข้อกังวลในการออกแบบ URL:

"ฉันจะออกแบบทรัพยากรของฉันได้อย่างไร" เป็นคำถามที่สำคัญสำหรับฉัน "ฉันจะออกแบบ URL ของฉันได้อย่างไร" เป็นการพิจารณาในสองด้าน:

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

หากJRandomUserต้องการดูโปรไฟล์ของเขาเองและคุณต้องการให้ URL นั้นสวยกว่าfoo.com/user/JRandomUserหรือfoo.com/user/(JRandom's numeric user id here)คุณสามารถสร้าง URL แยกต่างหากเพื่อให้ผู้ใช้ดูข้อมูลของตนเอง:

GET foo.com/profile /*examines cookies to figure out who 
                     * is logged in (SomeUser) and then 
                     * displays the same response as a
                     * GET to foo.com/users/SomeUser.
                     */

ฉันจะอ้างว่าไม่รู้ได้ง่ายกว่าภูมิปัญญาในเรื่องนี้ แต่นี่คือข้อควรพิจารณาในการออกแบบทรัพยากรบางประการ:

1. ผู้บริโภค: ทรัพยากรใดที่มีไว้เพื่อดูโดยตรงในเบราว์เซอร์โหลดผ่าน XHR หรือเข้าถึงโดยไคลเอนต์ประเภทอื่น
2. การเข้าถึง / ข้อมูลประจำตัว: การตอบสนองขึ้นอยู่กับคุกกี้หรือผู้อ้างอิงหรือไม่?

RESTful สามารถใช้เป็นแนวทางในการสร้าง URL และคุณสามารถสร้างเซสชันและทรัพยากรผู้ใช้ :

• GET /session/new รับหน้าเว็บที่มีแบบฟอร์มเข้าสู่ระบบ
• POST /session รับรองความถูกต้องข้อมูลประจำตัวกับฐานข้อมูล
• DELETE /session ทำลายเซสชันและเปลี่ยนเส้นทางไปยัง /
• GET /users/new รับหน้าเว็บที่มีแบบฟอร์มการลงทะเบียน
• POST /users บันทึกข้อมูลที่ป้อนลงในฐานข้อมูลในรูปแบบใหม่ / user / xxx
• GET /users/xxx // รับและแสดงข้อมูลผู้ใช้ปัจจุบันในมุมมองโปรไฟล์
• POST /users/xxx // อัปเดตข้อมูลใหม่เกี่ยวกับผู้ใช้

สิ่งเหล่านี้อาจเป็นพหูพจน์หรือเอกพจน์ (ฉันไม่แน่ใจว่าอันไหนถูกต้อง) โดยปกติฉันจะใช้/usersสำหรับหน้าดัชนีผู้ใช้ (ตามที่คาดไว้) และ/sessionsเพื่อดูว่าใครเข้าสู่ระบบ (ตามที่คาดไว้)

การใช้ชื่อใน URL แทนตัวเลข ( /users/43เทียบกับ/users/joe) มักเกิดจากความปรารถนาที่จะเป็นมิตรกับผู้ใช้หรือเครื่องมือค้นหามากกว่าไม่ใช่ข้อกำหนดทางเทคนิคใด ๆ ก็ดี แต่ฉันขอแนะนำให้คุณมีความสม่ำเสมอ

ฉันคิดว่าถ้าคุณไปด้วยการลงทะเบียน / เข้าสู่ระบบ / ออกจากระบบหรือsign(in|up|out)มันใช้ไม่ได้กับคำศัพท์ที่สงบ

เซสชันไม่สงบ

• ใช่ฉันรู้. กำลังดำเนินการเสร็จสิ้นโดยปกติจะใช้ OAuth แต่จริงๆแล้วเซสชันไม่ได้ RESTful คุณไม่ควรมีทรัพยากร / login / logout เป็นหลักเนื่องจากคุณไม่ควรมีเซสชัน

• หากคุณกำลังจะทำก็จงทำให้สงบ ทรัพยากรคือคำนามและ / เข้าสู่ระบบและ / ออกจากระบบไม่ใช่คำนาม ฉันจะไปกับ / ครั้ง สิ่งนี้ทำให้การสร้างและการลบเป็นการกระทำที่เป็นธรรมชาติมากขึ้น

• โพสต์กับ GET สำหรับเซสชันนั้นง่ายมาก หากคุณส่งผู้ใช้ / รหัสผ่านเป็นตัวแปรฉันจะใช้ POST เพราะไม่ต้องการให้ส่งรหัสผ่านเป็นส่วนหนึ่งของ URI มันจะปรากฏขึ้นในบันทึกและอาจมีการสัมผัสกับลวด นอกจากนี้คุณยังเสี่ยงต่อการที่ซอฟต์แวร์ล้มเหลวในข้อ จำกัด GET args

• โดยทั่วไปฉันใช้ Basic Auth หรือไม่มี Auth กับบริการ REST

การสร้างผู้ใช้

• เป็นแหล่งข้อมูลเดียวดังนั้นคุณไม่ควรต้องการ / ลงทะเบียน

  • POST / user - สร้างผู้ใช้หากผู้ร้องขอไม่สามารถระบุ id
  • PUT / user / xxx - สร้างหรืออัปเดตผู้ใช้โดยสมมติว่าคุณรู้รหัสล่วงหน้า
  • รับ / ผู้ใช้ - แสดงรายการ x รหัสผู้ใช้
  • รับ / ผู้ใช้ / xxx - รับรายละเอียดของผู้ใช้ด้วย id xxx
  • DELETE / user / xxx - ลบผู้ใช้ด้วย id xxx

• ประเภทของ ID ที่จะใช้เป็นคำถามที่ยาก คุณต้องคิดถึงการบังคับใช้ความเป็นเอกลักษณ์เกี่ยวกับการนำรหัสเก่าที่ถูก DELETEd มาใช้ซ้ำ ตัวอย่างเช่นคุณไม่ต้องการใช้รหัสเหล่านั้นเป็นคีย์ต่างประเทศบนแบ็กเอนด์หากรหัสกำลังจะถูกรีไซเคิล (ถ้าเป็นไปได้ทั้งหมด) คุณสามารถค้นหาได้แม้ว่าการแปลงรหัสภายนอก / ภายในเพื่อลดความต้องการของแบ็กเอนด์

ฉันจะพูดง่ายๆจากประสบการณ์ของฉันในการรวม REST Web Services ต่างๆสำหรับลูกค้าของฉันไม่ว่าจะใช้สำหรับแอพมือถือหรือการสื่อสารระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์รวมถึงการสร้าง REST API สำหรับผู้อื่น ต่อไปนี้เป็นข้อสังเกตบางประการที่ฉันได้รวบรวมจาก REST API ของผู้อื่นรวมถึงสิ่งที่เราสร้างขึ้นเอง:

• เมื่อเราพูดว่า API โดยปกติจะหมายถึงชุดของอินเตอร์เฟสการเขียนโปรแกรมและไม่จำเป็นต้องใช้เลเยอร์การนำเสนอ REST ยังเป็นศูนย์กลางข้อมูลและไม่ขับเคลื่อนการนำเสนอ ที่กล่าวว่า REST ส่งคืนข้อมูลในรูปแบบของ JSON หรือ XML และไม่ค่อยส่งคืนเลเยอร์การนำเสนอที่เฉพาะเจาะจง ลักษณะนี้ (ของการส่งคืนข้อมูลไม่ใช่หน้าเว็บโดยตรง) ทำให้ REST มีความสามารถในการจัดส่งแบบหลายช่องทาง หมายความว่าบริการเว็บเซิร์ฟเวอร์เดียวกันสามารถแสดงผลใน HTML, iOS, Android หรือแม้กระทั่งใช้เป็นเซิร์ฟเวอร์ร่วมกับเซิร์ฟเวอร์
• เป็นเรื่องยากมากที่จะรวมทั้ง HTML และ REST เป็น URL โดยค่าเริ่มต้น REST คือความคิดเป็นบริการและไม่มีเลเยอร์การนำเสนอ เป็นงานสำหรับผู้ที่ใช้บริการเว็บเพื่อแสดงข้อมูลจากบริการที่พวกเขาเรียกใช้ตามสิ่งที่พวกเขาต้องการ ด้วยเหตุนี้ URL ของคุณด้านล่างไม่สอดคล้องกับการออกแบบตาม REST ส่วนใหญ่ที่ฉันเคยพบมาจนถึงตอนนี้ (หรือมาตรฐานเช่นผู้ที่มาจาก Facebook หรือ Twitter)

รับ / ลงทะเบียน // รับหน้าเว็บที่มีแบบฟอร์มการลงทะเบียน

• ต่อจากจุดก่อนหน้านี้เป็นเรื่องผิดปกติ (และฉันไม่พบ) สำหรับบริการที่ใช้ REST ในการเปลี่ยนเส้นทางเช่นที่แนะนำด้านล่าง:

GET / logout // ทำลายเซสชันและเปลี่ยนเส้นทางไปยัง /
POST / login // รับรองความถูกต้องข้อมูลรับรองกับฐานข้อมูลและเปลี่ยนเส้นทางกลับบ้านด้วยเซสชันใหม่หรือเปลี่ยนเส้นทางกลับไปที่ / login
 

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

• ใน REST URL หมายถึงการดำเนินการที่เกิดขึ้น ด้วยเหตุนี้เราจึงควรลบความคลุมเครือให้มากที่สุด แม้ว่าจะถูกต้องในกรณีของคุณที่จะมีทั้ง GET และ POST ที่มีเส้นทางเดียวกัน (เช่น / ลงทะเบียน) ที่ดำเนินการต่างกัน แต่การออกแบบดังกล่าวทำให้เกิดความคลุมเครือในบริการที่มีให้และอาจทำให้ผู้บริโภคสับสนกับบริการของคุณ ตัวอย่างเช่น URL เช่นที่คุณแนะนำด้านล่างไม่เหมาะสำหรับบริการที่ใช้ REST

รับ / ลงทะเบียน // รับหน้าเว็บที่มีแบบฟอร์มการลงทะเบียน
POST / register // บันทึกข้อมูลที่ป้อนลงในฐานข้อมูลเป็น / user / xxx ใหม่

นี่คือบางจุดจากสิ่งที่ฉันได้จัดการ ฉันหวังว่ามันจะให้ข้อมูลเชิงลึกแก่คุณได้

สำหรับการใช้งาน REST ของคุณสิ่งเหล่านี้เป็นการใช้งานทั่วไปที่ฉันพบ:

• รับ / ออกจากระบบ  
  

  ดำเนินการออกจากระบบในแบ็กเอนด์และส่งคืน JSON เพื่อแสดงถึงความสำเร็จ / ล้มเหลวของการดำเนินการ

• POST / เข้าสู่ระบบ
  

  ส่งข้อมูลรับรองไปยังแบ็กเอนด์ คืนความสำเร็จ / ล้มเหลว หากสำเร็จโดยปกติจะส่งคืนโทเค็นเซสชันเช่นเดียวกับข้อมูลโปรไฟล์

• โพสต์ / ลงทะเบียน
  

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

• รับ / ผู้ใช้ / xxx
  

  รับโปรไฟล์ผู้ใช้และส่งคืนรูปแบบข้อมูล JSON สำหรับโปรไฟล์ของผู้ใช้

• โพสต์ / ผู้ใช้ / xxx 
  // เปลี่ยนชื่อเป็น 
  POST / updateUser / xxx
  

  โพสต์ข้อมูลโปรไฟล์ที่อัปเดตเป็นรูปแบบ JSON และอัปเดตข้อมูลในแบ็กเอนด์ คืนความสำเร็จ / ล้มเหลวให้กับผู้โทร

ฉันเชื่อว่านี่เป็นแนวทางที่ปลอดภัยในการตรวจสอบสิทธิ์ HttpPutเพื่อเข้าสู่ระบบที่คุณใช้ เมธอด HTTP นี้สามารถใช้สำหรับการสร้างเมื่อมีการให้คีย์และการเรียกซ้ำเป็นสิ่งที่ไม่จำเป็น สำหรับ LogOff คุณระบุพา ธ เดียวกันภายใต้HttpDeleteเมธอด ไม่มีการใช้คำกริยา การรวบรวมพหูพจน์ที่เหมาะสม วิธีการ HTTP สนับสนุนวัตถุประสงค์

[HttpPut]
[Route("sessions/current")]
public IActionResult LogIn(LogInModel model) { ... }

[HttpDelete]
[Route("sessions/current")]
public IActionResult LogOff() { ... }

หากต้องการคุณสามารถแทนที่กระแสที่ใช้งานได้

ฉันขอแนะนำให้ใช้ URL บัญชีผู้ใช้ที่คล้ายกับ twitter โดยที่ URL บัญชีของผู้ใช้จะเป็นบางอย่างเช่นfoo.com/myUserNameเดียวกับที่คุณสามารถเข้าถึงบัญชี twitter ของฉันด้วย URL https://twitter.com/joelbyler

ฉันไม่เห็นด้วยกับการออกจากระบบที่ต้องใช้ POST ในฐานะที่เป็นส่วนหนึ่งของ API ของคุณหากคุณกำลังจะรักษาเซสชัน ID เซสชันในรูปแบบของ UUID อาจเป็นสิ่งที่สามารถใช้เพื่อติดตามผู้ใช้และยืนยันว่าการดำเนินการที่ดำเนินการนั้นได้รับอนุญาต จากนั้นแม้แต่ GET ก็สามารถส่งผ่านรหัสเซสชันไปยังทรัพยากรได้

ในระยะสั้นฉันขอแนะนำให้คุณพูดง่ายๆ URL ควรสั้นน่าจดจำ