ความต้องการวิธีการเช่น GET และ POST ในโปรโตคอล HTTP คืออะไร?

เราไม่สามารถใช้โพรโทคอล HTTP โดยใช้เนื้อความการร้องขอและเนื้อความการตอบสนองได้หรือไม่

ตัวอย่างเช่น URL จะมีการร้องขอซึ่งจะถูกแมปไปยังฟังก์ชั่นขึ้นอยู่กับภาษาการเขียนโปรแกรมทางฝั่งเซิร์ฟเวอร์บอกว่า Servlet และในการตอบสนอง HTML และการตอบสนอง JavaScript จะถูกส่งผ่าน

ทำไมโปรโตคอล HTTP ถึงมีแนวคิดวิธีการ

จากคำตอบฉันเข้าใจว่าทำไมแนวคิดของวิธีการถึงอยู่ตรงนั้น .. นี่นำไปสู่คำถามอื่นที่เกี่ยวข้อง:

ตัวอย่างเช่นในลิงก์การเขียน gmail คำขอ PUT / POST และข้อมูลจะถูกส่ง เบราว์เซอร์จะรู้ได้อย่างไรว่าจะใช้วิธีใด หน้า gmail ที่ส่งโดยเซิร์ฟเวอร์มีชื่อวิธีที่จะใช้เมื่อโทร gmail เขียนคำขอหรือไม่ เมื่อเราเรียก www.gmail.com ต้องใช้วิธีการ GET เบราว์เซอร์รู้ได้อย่างไรว่าวิธีนี้ใช้

ป.ล. : ฉันมีเครดิตไม่เพียงพอที่จะแสดงความคิดเห็นต่อคำตอบดังนั้นฉันจึงไม่สามารถแสดงความคิดเห็นในคำถามมากมายที่คนที่เกี่ยวข้องกับความตั้งใจที่อยู่เบื้องหลังคำถามนี้

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

โปรดทราบว่าคำถามมีการเปลี่ยนแปลง / รับการชี้แจงตั้งแต่คำตอบนี้ถูกเขียนขึ้นครั้งแรก การตอบสนองต่อการทำซ้ำครั้งล่าสุดของคำถามคือหลังจากกฎแนวนอนที่สอง

ความต้องการวิธีการเช่น GET และ POST ในโปรโตคอล HTTP คืออะไร?

พวกเขาพร้อมกับสิ่งอื่น ๆ เช่นรูปแบบส่วนหัวกฎสำหรับวิธีการแยกส่วนหัวและร่างกายสร้างพื้นฐานของโปรโตคอล HTTP

เราไม่สามารถใช้โพรโทคอล HTTP โดยใช้เนื้อความการร้องขอและเนื้อความการตอบสนองได้หรือไม่

ไม่เพราะสิ่งที่คุณสร้างขึ้นจะไม่เป็นโปรโตคอล HTTP

ตัวอย่างเช่น URL จะมีการร้องขอซึ่งจะถูกแมปไปยังฟังก์ชั่นขึ้นอยู่กับภาษาการเขียนโปรแกรมทางฝั่งเซิร์ฟเวอร์บอกว่า Servlet และในการตอบสนอง HTML และการตอบสนอง JavaScript จะถูกส่งผ่าน

ขอแสดงความยินดีคุณเพิ่งคิดค้นโปรโตคอลใหม่! ตอนนี้ถ้าคุณต้องการตั้งค่าหน่วยมาตรฐานเพื่อขับเคลื่อนและบำรุงรักษาพัฒนา ฯลฯ มันสามารถแซง HTTP ได้ในวันหนึ่ง

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

กลับมาบนอินเทอร์เน็ตถ้าคุณเปิดซ็อกเก็ตไปยังเว็บเซิร์ฟเวอร์ที่สอดคล้องกับ HTTP และส่งต่อไปนี้:

EHLO
AUTH LOGIN

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

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

ถ้าเราใช้ตัวอย่างของคุณสักครู่ ที่ไคลเอนต์เชื่อมต่อและระบุสิ่งที่ดูเหมือน URL .. และเซิร์ฟเวอร์เข้าใจและส่งสิ่งที่ดูเหมือนว่า HTML / JS (เว็บเพจ) จากนั้นตรวจสอบว่ามันสามารถทำงานได้ คุณช่วยอะไรได้บ้าง? ไม่กี่ไบต์ที่ไม่ได้พูดว่า GET? มีอีกไม่กี่อย่างที่คิดว่าส่วนหัวที่น่ารำคาญ .. เซิร์ฟเวอร์ก็ช่วยคุณด้วยเช่นกัน - แต่ถ้าคุณไม่สามารถบอกได้ว่ามันส่งอะไรให้คุณล่ะ ถ้าคุณขอ URL ที่ลงท้ายด้วย JPEG และมันส่งให้คุณเป็นจำนวนไบต์ที่ทำให้รูปภาพ แต่เป็น PNG PNG ที่ไม่สมบูรณ์ในตอนนั้น ถ้าเพียง แต่เรามีส่วนหัวที่กล่าวว่าวิธีการหลายไบต์มันเป็นไปเพื่อส่งแล้วเราจะทราบว่าจำนวนไบต์ที่เราได้รับเป็นจริงทั้งไฟล์หรือไม่ จะทำอย่างไรถ้าเซิร์ฟเวอร์ตอบกลับเพื่อบันทึกแบนด์วิดท์ แต่ไม่ได้บอกคุณ คุณกำลังจะใช้พลังการประมวลผลจำนวนมากพยายามที่จะคิดออกสิ่งที่มันส่ง

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

การใช้วิธี HTTP ต่างๆนั้นจำเป็นจริงๆหรือ?

เนื้อหาไม่จำเป็นต้องใช้โปรโตคอลที่ระบุทั้งหมดและนี่เป็นเรื่องจริงสำหรับทุกสิ่ง ฉันไม่รู้ทุกคำในภาษาอังกฤษ; เพื่อนบ้านชาวจีนของฉันยังเป็นผู้พัฒนาซอฟต์แวร์ด้วย แต่ในอุตสาหกรรมที่แตกต่างกันและเขาไม่รู้ภาษาจีนแม้แต่คำศัพท์บางคำที่ใช้ในอุตสาหกรรมของฉันโดยไม่พูดภาษาอังกฤษ สิ่งที่ดีคือเราทั้งคู่สามารถรับเอกสารเกี่ยวกับการใช้งาน HTTP เขาสามารถเขียนเซิร์ฟเวอร์และฉันสามารถเขียนลูกค้าในภาษาการเขียนโปรแกรมที่แตกต่างกันในสถาปัตยกรรมที่แตกต่างกันและพวกเขายังคงทำงานเพราะพวกเขาปฏิบัติตามโปรโตคอล

อาจเป็นกรณีที่ผู้ใช้ของคุณจะไม่ออกสิ่งใดนอกจากคำขอ GET ไม่ใช้การเชื่อมต่อแบบถาวรส่งสิ่งอื่นใดนอกเหนือจาก JSON เป็นเนื้อความหรือต้องยอมรับสิ่งอื่นนอกเหนือจากข้อความ / ธรรมดาเพื่อให้คุณสามารถ เขียนเว็บเซิร์ฟเวอร์ที่มีปัญหามากซึ่งตรงกับความต้องการที่ จำกัด ของเบราว์เซอร์ไคลเอ็นต์ แต่คุณไม่สามารถตัดสินใจที่จะทำตามกฎพื้นฐานที่ทำให้ "ข้อความบางส่วนผ่านซ็อกเก็ต" ซึ่ง HTTP คืออะไร คุณไม่สามารถทิ้งความคิดพื้นฐานที่คำขอจะเป็นสตริงเช่น:

VERB URL VERSION
header: value

maybe_body

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

ปรับปรุง

คำถามของคุณพัฒนาไปเล็กน้อยต่อไปนี้เป็นคำตอบของสิ่งที่คุณถาม:

ทำไมโปรโตคอล HTTP ถึงมีแนวคิดวิธีการ

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

ที่ให้บริบททางประวัติศาสตร์บางอย่างสำหรับวิธีการ - กาลครั้งหนึ่ง URL เป็นบิตที่ไม่ยืดหยุ่นและอ้างถึงหน้าเว็บบนดิสก์อย่างง่ายดังนั้นวิธีนี้จึงมีประโยชน์เพราะอนุญาตให้ไคลเอนต์อธิบายความตั้งใจที่มีสำหรับไฟล์และเซิร์ฟเวอร์จะ ประมวลผลวิธีการในวิธีที่แตกต่างกันบางอย่าง ไม่มีความคิดเกี่ยวกับ URL ที่เป็นเสมือนหรือใช้สำหรับการสลับหรือการแมปในวิสัยทัศน์ดั้งเดิมของไฮเปอร์เท็กซ์ (และจริงๆแล้วมันเป็นข้อความเท่านั้น) เว็บ

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

การเขียนสคริปต์มาถึงจุดสิ้นสุดของไคลเอ็นต์และปลั๊กอินและส่วนขยายของเบราว์เซอร์ซึ่งมีจุดประสงค์เพื่อทำให้เบราว์เซอร์เป็นแหล่งพลังงานที่มีความสามารถอย่างมากในทุกสิ่ง ในตอนท้ายเซิร์ฟเวอร์การสร้างเนื้อหาที่ใช้งานบนพื้นฐานของอัลกอริทึมหรือฐานข้อมูลเป็นสิ่งที่ผลักดันอย่างใหญ่หลวงและมันก็ยังคงพัฒนาต่อไปจนอาจมีไฟล์บนดิสก์น้อยมาก - แน่นอนว่าเราเก็บรูปภาพหรือไฟล์สคริปต์ไว้เป็นไฟล์ เว็บเซิร์ฟเวอร์และให้เบราว์เซอร์รับมัน แต่ภาพที่เบราว์เซอร์แสดงและสคริปต์ที่ทำงานนั้นไม่ใช่ไฟล์ที่คุณสามารถเปิดใน file explorer ของคุณได้พวกเขากำลังสร้างเนื้อหาที่เป็นผลลัพธ์ของกระบวนการรวบรวมบางอย่างที่ทำได้ตามความต้องการ , SVG ที่อธิบายวิธีการวาดพิกเซลแทนที่จะเป็นบิตแมปอาเรย์พิกเซลหรือ JavaScript ที่ถูกปล่อยออกมาจากรูปแบบสคริปต์ระดับสูงกว่าเช่น TypeScript

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

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

จากคำตอบฉันเข้าใจว่าทำไมแนวคิดของวิธีการถึงอยู่ตรงนั้น .. นี่นำไปสู่คำถามอื่นที่เกี่ยวข้อง:

ตัวอย่างเช่นในลิงก์การเขียน gmail คำขอ PUT / POST และข้อมูลจะถูกส่ง เบราว์เซอร์จะรู้ได้อย่างไรว่าจะใช้วิธีใด

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

หน้า gmail ที่ส่งโดยเซิร์ฟเวอร์มีชื่อวิธีที่จะใช้เมื่อโทร gmail เขียนคำขอหรือไม่

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

วิธีการที่ทันสมัยในการทำสิ่งต่าง ๆ คือด้วยแอปพลิเคชันหน้าเดียว เบราว์เซอร์มีเอกสารในหน่วยความจำที่แสดงในลักษณะที่แน่นอนสคริปต์การโทรไปยัง theerverv และรับข้อมูลบางส่วนกลับมาและจัดการเอกสารเพื่อให้ส่วนหนึ่งของหน้าเปลี่ยนการมองเห็นเพื่อแสดงข้อมูลใหม่โดยไม่ต้องทำงาน เบราว์เซอร์เคยโหลดหน้าใหม่อีกครั้ง มันเพิ่งกลายเป็น UI ที่บางส่วนของมันอัปเดตเหมือนแอพไคลเอนต์ทั่วไปเช่น word หรือ outlook องค์ประกอบใหม่จะปรากฏที่ด้านบนขององค์ประกอบอื่น ๆ และสามารถลากไปรอบ ๆ หน้าต่างข้อความจำลองเป็นต้นทั้งหมดนี้คือเครื่องมือสร้างสคริปต์ของเบราว์เซอร์ที่ส่งคำขอโดยใช้วิธี http ที่นักพัฒนาต้องการรับข้อมูลกลับมา คุณสามารถเข้าใจว่าเบราว์เซอร์ที่ทันสมัยเป็นอุปกรณ์ที่ยอดเยี่ยมซึ่งเป็นเหมือนระบบปฏิบัติการทั้งหมดหรือคอมพิวเตอร์เสมือน อุปกรณ์ที่ตั้งโปรแกรมได้ซึ่งมีวิธีการที่เป็นมาตรฐานในการวาดภาพบนหน้าจอเล่นเสียงจับภาพอินพุตของผู้ใช้และส่งไปประมวลผล สิ่งที่คุณต้องทำเพื่อให้วาด UI ของคุณคือให้ html / css ที่ทำให้ UI นั้นปรับแต่ง html อย่างต่อเนื่องเพื่อให้เบราว์เซอร์เปลี่ยนสิ่งที่กำลังวาด Heck ผู้คนเคยชินกับการเห็นแถบที่อยู่เปลี่ยน / ใช้เป็นทิศทางของเจตนาที่แอพหน้าเดียวจะเปลี่ยน url โดยทางโปรแกรมแม้ว่าจะไม่มีการนำทาง (ขอหน้าใหม่ทั้งหมด) สิ่งที่คุณต้องทำเพื่อให้วาด UI ของคุณคือให้ html / css ที่ทำให้ UI นั้นปรับแต่ง html อย่างต่อเนื่องเพื่อให้เบราว์เซอร์เปลี่ยนสิ่งที่กำลังวาด Heck ผู้คนเคยชินกับการเห็นแถบที่อยู่เปลี่ยน / ใช้เป็นทิศทางของเจตนาที่แอพหน้าเดียวจะเปลี่ยน url โดยทางโปรแกรมแม้ว่าจะไม่มีการนำทาง (ขอหน้าใหม่ทั้งหมด) สิ่งที่คุณต้องทำเพื่อให้วาด UI ของคุณคือให้ html / css ที่ทำให้ UI นั้นปรับแต่ง html อย่างต่อเนื่องเพื่อให้เบราว์เซอร์เปลี่ยนสิ่งที่กำลังวาด Heck ผู้คนเคยชินกับการเห็นแถบที่อยู่เปลี่ยน / ใช้เป็นทิศทางของเจตนาที่แอพหน้าเดียวจะเปลี่ยน url โดยทางโปรแกรมแม้ว่าจะไม่มีการนำทาง (ขอหน้าใหม่ทั้งหมด)

เมื่อเราเรียก www.gmail.com ต้องใช้วิธีการ GET เบราว์เซอร์รู้ได้อย่างไรว่าวิธีนี้ใช้

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

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

ประวัติศาสตร์ มรดก ในทางทฤษฎีเราสามารถโยนวิธี http ทั้งหมดออกในวันพรุ่งนี้ - เราอยู่ในระดับความซับซ้อนของการเขียนโปรแกรมที่เมธอดล้าสมัยเนื่องจาก URL สามารถประมวลผลได้ในระดับที่พวกเขาสามารถเป็นกลไกการสลับที่บ่งชี้ไปยังเซิร์ฟเวอร์ที่คุณต้องการบันทึกข้อมูลใน เนื้อความเป็นแบบร่างอีเมลหรือลบแบบร่าง - ไม่มีไฟล์ / อีเมล / แบบร่าง / บันทึก / 1234 บนเซิร์ฟเวอร์ - เซิร์ฟเวอร์ถูกตั้งโปรแกรมให้เลือก URL ที่แยกออกจากกันและรู้ว่าจะทำอย่างไรกับข้อมูลร่างกาย - บันทึก เป็นอีเมลฉบับร่างภายใต้รหัส 1234

ดังนั้นจึงเป็นไปได้ที่จะกำจัดด้วยวิธีการยกเว้นความเข้ากันได้แบบดั้งเดิมที่มีน้ำหนักมากที่เติบโตรอบตัวพวกเขา มันจะดีกว่าที่จะใช้พวกเขาในสิ่งที่คุณต้องการ แต่ส่วนใหญ่ไม่สนใจพวกเขาและใช้สิ่งที่คุณต้องการเพื่อให้สิ่งที่คุณทำงาน เรายังคงต้องใช้วิธีการที่ได้รับการรับรองเนื่องจากคุณต้องจำไว้ว่าสิ่งเหล่านั้นมีความหมายต่อเบราว์เซอร์และเซิร์ฟเวอร์ที่เราได้สร้างแอพขึ้นมา สคริปต์ฝั่งไคลเอ็นต์ต้องการใช้เบราว์เซอร์ต้นแบบเพื่อส่งข้อมูลจำเป็นต้องใช้วิธีที่จะทำให้เบราว์เซอร์ทำตามที่ถาม - อาจเป็น POST เนื่องจาก GET จะบรรจุข้อมูลตัวแปรทั้งหมดลงใน URL และมีขีดจำกัดความยาว ในเซิร์ฟเวอร์จำนวนมาก ลูกค้าต้องการการตอบสนองที่ยาวนานจากเซิร์ฟเวอร์ - อย่าใช้ HEAD เพราะพวกเขาไม่ควรจะมีเนื้อหาตอบสนองเลย

HTTP อาจถือได้ว่าเป็นกรณีเฉพาะของหลักการทั่วไปของการเรียกใช้โปรซีเจอร์ระยะไกล: คุณบอกเซิร์ฟเวอร์ว่าคุณต้องการอะไรกับฟิลด์ตัวแปรบางตัวในคำขอเซิร์ฟเวอร์จะตอบสนองตามนั้น เมื่อถึงตอนนี้เนื่องจากการโต้ตอบที่ซับซ้อนของ 'Web 2.0' คุณสมบัติเดียวกันเหล่านี้ได้รับการผลักดันในทุกด้านตามคำขอ: URL, ส่วนหัว, เนื้อหา - และผู้ใช้งานและแอปแต่ละคนเข้าใจพวกเขาในแบบของพวกเขาเอง อย่างไรก็ตามในขั้นต้นเว็บนั้นเรียบง่ายกว่าใช้หน้าเว็บแบบสแตติกและคิดว่าวิธี HTTP ที่มีให้สำหรับระดับการโต้ตอบที่พอเพียง โดยเฉพาะอย่างยิ่ง HTTP มีวิธีการมากมายที่ใช้น้อยมากหากมีบางวิธีก็มองเห็นแสงได้ด้วย REST ตัวอย่างเช่น PUT และ DELETE เป็นปัญหาร้ายแรงก่อนที่ REST และการติดตามและ PATCH นั้นยังคงมองไม่เห็น สิ่งที่ควรหลีกเลี่ยงคือโมเดล RPC ของ HTTP ไม่ได้ '

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

โปรดทราบว่าเมธอด HTTP มีการกำหนดซีแมนทิกส์สำหรับเบราว์เซอร์และมิดเดิลแวร์เช่นพร็อกซีเซิร์ฟเวอร์: คำขอ POST, PUT, DELETE และ PATCH อาจมีผลข้างเคียงและน่าจะไม่เป็น idempotent ดังนั้นแอปฝั่งไคลเอ็นต์และมิดเดิลแวร์จึงระมัดระวัง เพื่อไม่ดำเนินการตามคำขอเหล่านี้โดยไม่มีการดำเนินการอย่างชัดเจนจากผู้ใช้ ในทางปฏิบัติเว็บแอปที่ออกแบบมาไม่ดีใช้ GET สำหรับการกระทำที่ไม่ปลอดภัยและเช่นprefetcher ของ Google Web Accelerator ทำให้เกิดปัญหาโดยการลบข้อมูลจำนวนมากบนไซต์ดังกล่าวดังนั้นเบต้าของมันจึงถูกระงับในไม่ช้าหลังจากเปิดตัว

ดังนั้นเพื่อตอบคำถาม 'เราจะทำอย่างไร': แน่นอนคุณต้องเห็นด้วยกับโพรโทคอลที่จะบอกแอปเซิร์ฟเวอร์ว่าคุณต้องการทำอะไรจากนั้นจึงใส่อาร์กิวเมนต์ใน URL / เนื้อหาเช่น รายการเป้าหมายสำหรับการดำเนินการ ชุดของการกระทำนั้น จำกัด เฉพาะแอพบางตัวเท่านั้นดังนั้นคุณต้องมีโปรโตคอลที่สามารถขยายได้ แต่คุณจะต้องแจ้งให้แอปไคลเอ็นต์ทราบว่าคำขอใดปลอดภัยและอาจต้องคำนึงถึงความแตกต่างอื่น ๆ เช่นการควบคุมแคช

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

ตัวอย่าง:

GET https://example.com/api/products/1234

สิ่งนี้จะดึงรายละเอียดของผลิตภัณฑ์ 1234

POST https://example.com/api/products/1234

สิ่งนี้จะสร้างผลิตภัณฑ์ที่มี ID 1234 โดยใช้ข้อมูลในส่วนคำขอ

PUT https://example.com/api/products/1234

สิ่งนี้จะอัปเดตผลิตภัณฑ์ 1234 พร้อมข้อมูลในเนื้อหาคำขอ

DELETE https://example.com/api/products/1234

จะเป็นการลบผลิตภัณฑ์ที่มี ID 1234

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

ความต้องการวิธีการเช่น GET และ POST ในโปรโตคอล HTTP คืออะไร?

ดูเหมือนว่าคุณลืมวันเก่าเมื่อเซิร์ฟเวอร์ HTTP อยู่ที่นั่นเพียงเพื่อให้บริการไฟล์ ; ไม่ใช้งานสคริปต์ CGI หรือสร้างเนื้อหาแบบไดนามิกของการจัดเรียงนั้น

วิธีการร้องขอเป็นพื้นฐานมาตรฐานชุดของคำกริยาในสิ่งที่ต้องทำกับไฟล์เหล่านั้น ...

• GET หมายถึงการดาวน์โหลด
• HEAD หมายถึงรับข้อมูลของ
• PUT หมายถึงการอัปโหลด
• DELETE หมายถึงการลบ
• POST หมายถึงส่งข้อมูลเข้า
• ตัวเลือกหมายถึงบอกสิ่งที่ฉันสามารถทำได้

ในวันที่ HTTP / 0.9 สายร้องขอเพียงสิ่งเดียวในขาคำขอของโปรโตคอล; ไม่มีส่วนหัวคำขอไม่มีส่วนหัวการตอบสนอง คุณเพียงแค่พิมพ์กดเซิร์ฟเวอร์จะส่งคืนเนื้อหาการตอบสนอง (เช่นเนื้อหา HTML) และโอเคขอบคุณลาก่อน (เช่นปิดการเชื่อมต่อ)GET /somefileEnter

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

อย่างไรก็ตามหากคุณต้องการถามเกี่ยวกับวิธีการปฏิบัติความหมายเหล่านี้ในแอพพลิเคชันเซิร์ฟเวอร์ที่ทันสมัย ...

เราไม่สามารถใช้โพรโทคอล HTTP โดยใช้เนื้อความการร้องขอและเนื้อความการตอบสนองได้หรือไม่

การใช้วิธี HTTP ต่างๆนั้นจำเป็นจริงๆหรือ?

คำตอบของฉันคือทำสิ่งที่คุณต้องการจะทำ แต่เก็บไว้ในใจที่คุณไม่ควรใช้ตรรกะการประยุกต์ใช้ในทางที่ได้อย่างหวุดหวิดคาดหวังของโปรโตคอล : ความคาดหวังเช่น GET ไม่ควรเปลี่ยนข้อมูล (หรือมากคับมีอย่างน้อยidempotentผล ) HEAD ควรมีผลลัพธ์เช่นเดียวกับ GET แต่ไม่มีเนื้อความการตอบสนอง PUT ควรทำให้เนื้อหาของ URI เป้าหมายพร้อมใช้งาน (หากสำเร็จ)

หากคุณขัดแย้งกับความคาดหวังโดยไม่คำนึงถึงผลกระทบของสิ่งต่าง ๆ ที่เกิดขึ้นเช่น ...

• เมื่อคุณใช้วิธีรับการใช้การส่งข้อมูลเซิร์ฟเวอร์อาจพ่นข้อผิดพลาด" URI Too Long " 414 หน้าของคุณ
• เมื่อคุณใช้วิธีรับการเปลี่ยนแปลงข้อมูลคุณจะพบว่าการแก้ไขบางครั้งไม่ผ่านเมื่อผู้ใช้อยู่หลังแคชพร็อกซีหรือการแก้ไขที่ไม่คาดคิดเกิดขึ้นเมื่อผู้ใช้เรียกคืน URL จากที่คั่นหน้าเว็บ (หรือเมื่อโปรแกรมรวบรวมข้อมูลเว็บเข้าถึง) .
• เมื่อคุณตอบสนองต่อวิธี HEAD อย่างไม่ถูกต้องคุณจะพบว่าเครื่องมือตรวจสอบเว็บไซต์อัตโนมัติของคุณ (เช่นwget --spider) ประกันตัวในเว็บไซต์ของคุณ
• เมื่อคุณใช้วิธี POST ในการดาวน์โหลดเนื้อหาคุณจะพบว่าการคั่นหน้าเว็บหรือแม้กระทั่งการป้อน URL ลงในเบราว์เซอร์จะไม่ทำงาน
• และอื่น ๆ อีกมากมาย...

" มือใหม่รู้กฎ แต่ทหารผ่านศึกรู้ข้อยกเว้น "

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

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

การละเมิดมาตรฐานอย่างไม่ตั้งใจหมายความว่าคุณกำลังใช้การเลือกปฏิบัติกับผู้ใช้ของคุณ

มันเป็นความจริงในทางทฤษฎีที่เราสามารถใช้รับได้ทั่วสถานที่และมันจะเรียงลำดับของการทำงาน ซอฟต์แวร์บางตัวใช้ GET กับคำขอเนื้อหา (ฉันกำลังมองหาคุณด้วย elasticsearch / kibana) แน่นอนว่านี่เป็นสิ่งที่น่ากลัว

เหตุผลที่สำคัญที่สุดเนื่องจากวิธีการต่าง ๆ มีความหมายที่แตกต่างกัน บางคนมีความปลอดภัยบางคนมี idempotent บางคนมีทั้ง ดูว่าอันไหน

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

ดูว่าจะเกิดอะไรขึ้นถ้าคุณใช้ GET โดยที่คุณควรใช้ POST

คุณยังสามารถนึกถึง GET, POST และอื่น ๆ เป็น overloads ของฟังก์ชั่นเดียวกันหรือแม้กระทั่งเป็น getters และ setters

GET_MyVar() จะไม่ใช้พารามิเตอร์อินพุต (หรือที่เรียกว่า Request Body) แต่จะส่งคืนบางสิ่ง

POST_MyVar(string blah)ทำสิ่งที่มีอินพุต (อีกครั้งเนื้อหาคำขอ) และอาจส่งคืนบางสิ่งบางอย่าง (อย่างน้อยก็ต้องส่งคืนรหัสตอบกลับเพื่อให้เรารู้ว่าฟังก์ชั่นทำงาน !!)

DELETE_MyVar() นอกจากนี้อาจไม่ใช้อะไรและคาดว่าจะลบบางสิ่ง

ใช่เราสามารถใช้ทั้งหมดได้ด้วย:
MyVar(string Action, string? blah)

วิธีนี้เราสามารถรับสายเดียวจากนั้นเลือกสิ่งที่ต้องทำตามพารามิเตอร์อื่น ๆ

แต่หนึ่งในความสะดวกสบายของวิธีการนี้คือช่วยให้เบราว์เซอร์และเซิร์ฟเวอร์สามารถปรับวิธีการทำงานของสิ่งเหล่านี้ให้เหมาะสม Action==DELETEยกตัวอย่างเช่นอาจจะเซิร์ฟเวอร์ต้องการที่จะปิดกั้นการร้องขอทั้งหมดที่ บางทีเบราว์เซอร์ต้องการแคชสิ่งที่Action==GET.ถ้าไม่ในทุกฟังก์ชั่นเราจะต้องเขียนif (Action==Delete) {return AngryFace}

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

วิธีการ HTTP ให้บริการเพื่อวัตถุประสงค์ที่แตกต่างกัน โดยทั่วไปGETสำหรับการดาวน์โหลดและPOSTสำหรับการอัปโหลด

วิธีเดียวที่ใช้เป็นส่วนหนึ่งของโปรโตคอล HTTP POSTโดยใช้เพียงร่างกายคำขอและร่างกายตอบสนองจะมีการดำเนินการ GETไม่มีเนื้อหาคำขอ มีเพียงส่วนหัวที่ร้องขอ แต่ไม่มีเนื้อหา มันเป็นเพียงแค่ขอให้เอกสารดาวน์โหลด POSTมีทั้งคำขอเนื้อหา (อัปโหลดไฟล์) และเนื้อหาตอบกลับ (เอกสารแสดงผลลัพธ์)

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

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

ไม่ว่าในกรณีใดไม่มีเหตุผลที่ดีที่จะใช้เว็บเซิร์ฟเวอร์สำหรับเว็บไซต์ของคุณตั้งแต่เริ่มต้น โปรโตคอล HTTP มีความซับซ้อน นอกเหนือจากวิธีการต่าง ๆ ที่คุณจะต้องใช้ pipelining และ chunked ร้องขอ มันง่ายกว่ามากในการสร้างเว็บแอปพลิเคชันของคุณบนเว็บเซิร์ฟเวอร์เช่น Apache, Nginx หรือ IIS ที่จัดการโปรโตคอล HTTP สำหรับคุณ คุณพูดถึง Servlets ดังนั้นบางทีคุณควรใช้ Tomcat หรือ JBoss เว็บเซิร์ฟเวอร์ที่เรียกใช้ Servlets

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

โปรโตคอลที่คุณเสนอจะปลอดภัยน้อยกว่าแฮกเกอร์อย่างมาก

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