ฉันควรจะอนุญาตพารามิเตอร์ที่ไม่รู้จักหรือไม่?


12

ฉันกำลังออกแบบ RESTful API และประสบกับปัญหาชื่อเรื่องซึ่งได้รับการปรับปรุงใหม่เพื่อความชัดเจน:

ฉันควรจะล้มเหลวอย่างรวดเร็วหากลูกค้าส่งพารามิเตอร์ที่ไม่รู้จัก? ตัวอย่างเช่น,

http://example.com/api/foo?bar=true&paula=bean

ในด้านบนbarเป็นพารามิเตอร์ที่ถูกต้อง แต่paulaไม่ได้ระบุไว้โดย API ฉันควร

  • เตือนให้ลูกค้าทราบถึงข้อผิดพลาด
  • ล้มเหลวอย่างรวดเร็ว
  • ไม่ต้องสนใจมัน

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

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

ข้อโต้แย้งของฉันสมเหตุสมผลหรือไม่ มีวิธีปฏิบัติที่เป็นที่ยอมรับในเรื่องดังกล่าวหรือไม่?


จากการทดสอบขนาดเล็กไซต์ทั้งหมดที่ฉันทดสอบนั้นไม่สนใจพารามิเตอร์ที่ไม่รู้จักที่ฉันให้มา
Bart van Ingen Schenau

@BartvanIngenSchenau เหมือนกันที่นี่ ไม่เป็นไรสำหรับหน้าเว็บ แต่ฉันไม่คิดว่ามันดีสำหรับ API ที่แท้จริง
rath

2
ข้อกังวลคือความเข้ากันได้ไปข้างหน้า หากไม่มีการโต้แย้งที่ไม่รู้จักมันเป็นไปได้ที่จะใช้มันในเวอร์ชันในอนาคตในลักษณะที่ลูกค้าสามารถตั้งโปรแกรมให้กับ API ใหม่และยังคงได้รับพฤติกรรมที่เหมาะสมบนเซิร์ฟเวอร์เก่า
walpen

@ Walpen นั่นเป็นจุดที่น่าสนใจ การใช้ URL ที่เป็นเวอร์ชันapi/v1ฯลฯ จะดูแลสิ่งนั้น แต่ก็ยังไม่อนุญาตสำหรับการอัปเดตที่เพิ่มขึ้น +1
rath

มีคุณสามารถค้นหาโปรบางและข้อเสียจากมุมมองสดจริง: พารามิเตอร์ที่เข้มงวดและ API
Remek Ambroziak

คำตอบ:


12

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

วิธีการที่เน้นการปฏิบัติมากขึ้นอาจไม่สนใจ params ที่ไม่ถูกต้อง แต่ไม่ว่าคุณจะไปทางไหน


1
ในฐานะที่เป็นส่วนขยาย: หากลูกค้าส่งพารามิเตอร์ที่ไม่รู้จัก / อ่านแล้ว / เลิกใช้แล้วนั่นหมายความว่าลูกค้าคาดว่าจะมีพฤติกรรมบางอย่างที่จะไม่สำเร็จ และดังนั้นจึงเป็นอันตรายที่จะทำการกระทำใด ๆ ดังนั้นฉันจึงเห็นด้วยคำขอไม่ดีอย่างเคร่งครัด
Stepan Stepanov

ขอบคุณ @StepanStepanov แต่มี "อนุญาตในสิ่งที่คุณยอมรับอย่างชัดเจนเกี่ยวกับสิ่งที่คุณส่งออก" ปรัชญาพื้นฐานของสถาปัตยกรรมเว็บ โดยที่ในใจฉันสามารถเขียนคำตอบตรงข้ามกับที่ฉันเขียนไว้ได้อย่างง่ายดาย
RubberDuck

3
ฉันได้ทำสิ่งนี้)) และหน้าเกี่ยวกับกฎของ Postel ยังบอกด้วยว่า "รหัสที่รับอินพุตควรยอมรับอินพุตที่ไม่สอดคล้องกันตราบใดที่ความหมายชัดเจน" ฉันคิดว่าถ้าลูกค้าส่งพารามิเตอร์ที่ไม่รู้จักมาให้เราความหมายของมันจะไม่ชัดเจน หากลูกค้าส่งพารามิเตอร์ที่ไม่สนับสนุนซึ่งชัดเจนว่าจะไม่ทำงานเหมือนก่อนและตามที่ลูกค้าคาดหวัง หากลูกค้าส่งพารามิเตอร์แบบอ่านอย่างเดียวให้เรามันชัดเจนว่ามันจะไม่ถูกเขียนตามที่ลูกค้าต้องการ
Stepan Stepanov

0

หากคุณใช้ API สาธารณะ (หรือ api ที่ทีมอื่นจะใช้) ฉันจะแนะนำข้อผิดพลาดคืนตามที่ @RubberDuck แนะนำ

หาก api ของคุณจะถูกใช้ภายในทีมของคุณเท่านั้น (หรือด้วยตัวคุณเองเท่านั้น) การละเว้นฟิลด์พิเศษ (เช่นต้องใช้รหัสน้อยลงและง่ายต่อการทำ) อาจทำได้ง่ายกว่า

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