ฉันมีทรัพยากรชุดหนึ่งที่มีการสร้างตัวแทนขึ้นมาอย่างเกียจคร้าน การคำนวณเพื่อสร้างการแสดงเหล่านี้อาจใช้เวลาตั้งแต่ไม่กี่มิลลิวินาทีจนถึงสองสามชั่วโมงขึ้นอยู่กับการโหลดของเซิร์ฟเวอร์ทรัพยากรเฉพาะและระยะของดวงจันทร์
คำขอ GET แรกที่ได้รับสำหรับทรัพยากรเริ่มต้นการคำนวณบนเซิร์ฟเวอร์ หากการคำนวณเสร็จสิ้นภายในไม่กี่วินาทีการแทนค่าที่คำนวณจะถูกส่งกลับ มิฉะนั้นรหัสสถานะ 202 "ยอมรับ" จะถูกส่งกลับและลูกค้าจะต้องสำรวจทรัพยากรจนกว่าจะมีการเป็นตัวแทนขั้นสุดท้าย
สาเหตุของพฤติกรรมนี้มีดังต่อไปนี้: หากผลลัพธ์พร้อมใช้งานภายในไม่กี่วินาทีจำเป็นต้องดึงข้อมูลโดยเร็วที่สุด มิฉะนั้นจะพร้อมใช้งานเมื่อใดก็ไม่สำคัญ
เนื่องจากหน่วยความจำที่ จำกัด และจำนวนคำขอที่มากขึ้นทั้ง NIO หรือการสำรวจความคิดเห็นแบบยาวจึงไม่มีทางเลือก ( กล่าวคือฉันไม่สามารถเปิดการเชื่อมต่อได้เกือบเพียงพอและฉันไม่สามารถใส่คำขอทั้งหมดลงในหน่วยความจำได้เลยแม้แต่ครั้งเดียว "ไม่กี่วินาที" ผ่านไปแล้วฉันยังคงดำเนินการตามคำขอส่วนเกิน) ในทำนองเดียวกันข้อ จำกัด ของไคลเอ็นต์คือไม่สามารถจัดการกับการโทรกลับที่สมบูรณ์แทนได้ สุดท้ายโปรดทราบว่าฉันไม่สนใจที่จะสร้างทรัพยากร "โรงงาน" ที่โพสต์หนึ่งรายการเนื่องจากการปัดเศษพิเศษหมายความว่าเราล้มเหลวข้อ จำกัด แบบเรียลไทม์แบบเป็นรายชิ้นมากกว่าที่ต้องการ (ยิ่งไปกว่านั้นมันซับซ้อนเป็นพิเศษนอกจากนี้ยังเป็นทรัพยากรที่จะ ประโยชน์จากการแคช)
ฉันคิดว่ามีข้อโต้แย้งเกี่ยวกับการส่งคืนรหัสสถานะ 202 "ที่ยอมรับ" เพื่อตอบสนองต่อคำขอ GET โดยที่ฉันไม่เคยเห็นในทางปฏิบัติและการใช้งานที่ง่ายที่สุดคือการตอบสนองต่อวิธีการที่ไม่ปลอดภัย แต่ฉันไม่เคย พบสิ่งที่ทำให้ท้อใจเป็นพิเศษ ยิ่งไปกว่านั้นฉันไม่ได้รักษาทั้งความปลอดภัยและความเป็นส่วนตัวใช่หรือไม่?
แล้วคนคิดอย่างไรเกี่ยวกับแนวทางนี้?
แก้ไข : ฉันควรพูดถึงสิ่งนี้สำหรับเว็บ API ที่เรียกว่าธุรกิจไม่ใช่สำหรับเบราว์เซอร์
202. สิ่งที่แทบจะไม่ได้ใช้ในทางปฏิบัติคือ IMHO มากกว่าเนื่องจากนักพัฒนาเว็บเพียงไม่กี่รายสนใจเกี่ยวกับรหัสสถานะที่เหมาะสมเนื่องจากพวกเขาคุ้นเคยกับการโต้ตอบกับเบราว์เซอร์ / ตัวแทนผู้ใช้มากกว่าซึ่งในกรณีนี้ a202จะทำให้พวกเขาไม่มีเงื่อนงำที่มองเห็นได้ (ให้200และพวกเขามีความสุข .. ).