สิ่งที่อยู่ในส่วนหัวคำขอ HTTP กับส่วนเนื้อหาร้องขอ


51

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

มีการแนะนำให้ใส่ไว้ในส่วนหัว HTTP ที่กำหนดเองเนื่องจากจะรวมอยู่กับคำขอทั้งหมดดังนั้นฉันจึงเริ่มสงสัยว่าเกณฑ์ใดที่จะใช้ในการพิจารณาว่าชิ้นส่วนของข้อมูลที่กำหนดนั้นเป็นของส่วนหัวหรือพร้อมกับข้อมูลอื่น ๆ ใน ร่างกายร้องขอ

มีเกณฑ์ดังกล่าวหรือไม่?


คำตอบ:


51

เมื่อข้อมูลมีความสำคัญคุณควรใส่เข้าไปในร่างกาย

ทำไม?

  1. พร็อกซีเซิร์ฟเวอร์ได้รับอนุญาตให้แก้ไขส่วนหัว หลายคนถูกกำหนดค่าให้ตัดส่วนหัวใด ๆ ที่พวกเขาไม่ทราบ อย่างไรก็ตามสิ่งนี้จะใช้เฉพาะเมื่อคุณใช้ HTTP ที่ไม่ได้เข้ารหัส เมื่อคุณใช้ HTTPS พร็อกซีจะไม่สามารถเปลี่ยนส่วนหัวได้เนื่องจากมีการเข้ารหัส
  2. เมื่อคุณใช้บริการเว็บคุณมักจะใช้งานร่วมกับอุปกรณ์บริการและเครื่องมืออื่น ๆ APIs และเครื่องมือส่วนใหญ่ที่ทำงานกับ webservices สามารถเปลี่ยนคำขอได้อย่างง่ายดาย แต่ส่วนมากทำให้ยากหรือเป็นไปไม่ได้ที่จะเพิ่มส่วนหัวที่กำหนดเอง แน่นอนว่าสิ่งนี้มีผลบังคับใช้เฉพาะเมื่อมีข้อกังวลเกี่ยวกับการทำงานร่วมกัน แต่เมื่อคุณไม่สนใจคุณอาจต้องถามตัวเองว่าทำไมคุณถึงใช้เว็บเซอร์ตั้งแต่แรกแทนที่จะสร้างโปรโตคอลของคุณเองบน raw TCP

คำตอบที่ดี - ข้อพิจารณาสองประการที่สมเหตุสมผลกับฉัน แต่ฉันไม่ได้รับการสอนมาก่อน
R Claven

1
ฉันเป็นรุ่นเก่า แต่ฉันเข้าร่วมชุมชนนี้เพียงเพื่อโหวตคำตอบนี้ ความรุ่งโรจน์
โพแทสเซียมไอออน

22

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

อีกวิธีหนึ่งในการดูคือ: ข้อมูลที่ปรากฏในคำขอเฉพาะประเภทควรอยู่ในเนื้อหาส่วนข้อมูลที่จัดการอย่างสม่ำเสมอตลอดทั้งแอปพลิเคชันควรเข้าสู่ส่วนหัว

อีกมุมมองหนึ่งคือคุณสามารถจินตนาการว่ามีการจัดการข้อมูลทั่วโลกเช่นเราเตอร์ / ไฟร์วอลล์แทนที่จะใช้แอปพลิเคชันของคุณหรือไม่? ถ้าใช่มันน่าจะไปที่ส่วนหัวมากกว่าในร่างกาย

ตัวอย่างของการใช้กฎเหล่านี้คือ:

  • ข้อมูลรับรองความปลอดภัยจะเข้าสู่ส่วนหัวเนื่องจากส่วนใหญ่พวกเขาจะได้รับการจัดการเหมือนกันในทุกสถานที่ของแอปพลิเคชัน ในระดับการใช้งานอาจมีบางตัวกรองคำขอปฏิเสธคำขอโดยไม่ต้องมีข้อมูลประจำตัวที่ถูกต้องโดยไม่คำนึงถึงจุดสิ้นสุดที่เกิดขึ้นจริงจัดการคำขอในกรณีที่มันได้รับผ่านตัวกรอง
  • หากในอีกทางหนึ่งคุณมีจุดปลายที่อนุญาตให้ผู้ดูแลระบบเพิ่มผู้ใช้ในระบบของคุณการล็อกอินของผู้ใช้ที่จะสร้างควรอยู่ในเนื้อความคำขอตั้งแต่: ก) มันถูกจัดการโดยตรรกะทางธุรกิจของแอปพลิเคชันของคุณ b) จะปรากฏในจุดปลายเฉพาะนี้ แต่ไม่ปรากฏในจุดอื่น
  • ตัวเลือกที่การควบคุมแคชอาจเหมาะสมกับส่วนหัว (เว้นแต่การแคชเป็นส่วนหลักของตรรกะทางธุรกิจของแอปพลิเคชันของคุณ)

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


0

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

หรือ

คุณสมบัติของเนื้อหาข้อความ / เนื้อหาจะเข้าสู่ส่วนหัว เช่น) ประเภทการเข้ารหัสความยาวเนื้อหาเนื้อหาประเภท

และ

ในกรณีของคุณเช่นพารามิเตอร์ตัวกรองควรจะเพิ่มเป็นแบบสอบถาม / คำขอพารามิเตอร์ใน URL

/mobiles?type=MOTO&colour=black

ในการให้บริการแบบสงบ url เองจะอ้างถึงวัตถุ

/conferences/{conference_id} -> หมายถึงการประชุมเฉพาะ


นี่เป็นคำพูดหรือไม่? จากที่ไหน ทำไมคุณถึงแนะนำสิ่งนี้ โปรดแก้ไขคำตอบของคุณเพื่อให้ดีขึ้น
Machado
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.