REST APIs: ส่วนหัว HTTP ที่กำหนดเองเทียบกับพารามิเตอร์ URL

คุณใช้ส่วนหัว HTTP ที่กำหนดเองในส่วนคำขอของ REST API เมื่อใด

ตัวอย่าง:

คุณเคยใช้

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

แทน

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

URL บ่งชี้ทรัพยากรเอง "ไคลเอนต์" เป็นทรัพยากรที่สามารถดำเนินการได้ดังนั้นควรเป็นส่วนหนึ่งของ URL พื้นฐาน: /orders/view/client/23ฐาน:

พารามิเตอร์มีไว้เพื่อกำหนดพารามิเตอร์การเข้าถึงทรัพยากร /orders/find?q=blahblah&sort=fooโดยเฉพาะอย่างยิ่งนี้มาลงเล่นกับโพสต์และการค้นหา: /orders/view/client/23/active versus /orders/view/client/23?show=activeมีเส้นแบ่งระหว่างค่าพารามิเตอร์และทรัพยากรย่อยเป็น: ขอแนะนำรูปแบบทรัพยากรย่อยและพารามิเตอร์สำรองสำหรับการค้นหา

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

HTTP มีส่วนหัวให้เลือกมากมายซึ่งครอบคลุมทุกสิ่งที่คุณต้องการ ที่ฉันเคยเห็นส่วนหัวแบบกำหนดเองปรากฏขึ้นในระบบเพื่อขอระบบปฏิบัติการในนามของผู้ใช้ ระบบพร็อกซีจะตรวจสอบความถูกต้องของผู้ใช้และเพิ่ม " X-User: userid" ในส่วนหัวและใช้ข้อมูลรับรองของระบบเพื่อเข้าสู่จุดสิ้นสุด ระบบรับจะตรวจสอบว่าข้อมูลรับรองระบบได้รับอนุญาตให้ดำเนินการในนามของผู้ใช้จากนั้นตรวจสอบว่าผู้ใช้ได้รับอนุญาตให้ดำเนินการ

ส่วนหัวที่กำหนดเองมีข้อดีดังต่อไปนี้:

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

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

คุณใช้ ... ส่วนหัว HTTP ในส่วนคำขอของ REST API เมื่อใด

การพิสูจน์ตัวตน: GUID การพิสูจน์ตัวตนขั้นพื้นฐานโทเค็นที่กำหนดเอง ฯลฯ เช่นการ รับรองความถูกต้องพื้นฐานด้วยโทเค็น Guid สำหรับ REST api แทนชื่อผู้ใช้ / รหัสผ่าน

หากคุณมีส่วนร่วมในการส่งโทเค็นหรือข้อมูลที่คล้ายการพิสูจน์ตัวตนอื่น ๆ ระหว่างโดเมนที่ครอบคลุมโดย PCI-DSS หรือกฎความปลอดภัยอื่น ๆ คุณอาจต้องฝังพารามิเตอร์เนื่องจากกฎระเบียบบางอย่างต้องการองค์ประกอบการตรวจสอบความถูกต้องอย่างชัดเจนเพื่อไม่ให้ URL ที่สามารถเล่นซ้ำได้เล็กน้อย (จาก ประวัติเบราว์เซอร์บันทึกพร็อกซี ฯลฯ )

ไม่มีมาตรฐานสำหรับ REST แต่วิธีที่ยอมรับจะเป็น

GET /orders/view/23

ไม่ใช้ส่วนหัวที่กำหนดเองดังนั้น 23 after view จึงถือว่าเป็น id ดังนั้นคุณจะมีฟังก์ชันที่ใช้ใน id และด้วยเหตุนี้จึงสร้างข้อมูลเพียงอย่างเดียว

ฉันจะไม่ใช้ส่วนหัวที่กำหนดเองเนื่องจากคุณไม่รู้ว่าพร็อกซีจะส่งต่อสิ่งเหล่านั้นหรือไม่ ตาม URL เป็นวิธีที่จะไป

รับ / สั่งซื้อ / ดู / ลูกค้า / 23

ตกลงแน่นอน:

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

ตกลงเช่นกัน:

GET /orders/view/23 or 

ฉันคิดว่ามันก็โอเคเช่นกัน:

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23

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