คำถามติดแท็ก api-design

Application Programming Interface (API) การออกแบบกล่าวถึงแนวปฏิบัติที่ดีที่สุดสำหรับการสร้างไลบรารีสำหรับวัตถุประสงค์ทั่วไปหรือการใช้สาธารณะ

14
คุณควรเขียน back-end ของคุณเป็น API หรือไม่?
วันนี้ฉันมีการสนทนาที่ร้อนแรงเกี่ยวกับแอปพลิเคชัน MVC ของเรา เรามีเว็บไซต์ที่เขียนใน MVC ( ASP.NET ) และโดยปกติจะเป็นไปตามรูปแบบของการทำอะไรบางอย่างในมุมมอง -> กดคอนโทรลเลอร์ -> คอนโทรลเลอร์สร้างโมเดล (เรียกผู้จัดการที่รับข้อมูลสร้างโมเดลใน วิธีการควบคุมเอง) -> โมเดลไปที่ดู -> ล้างและทำซ้ำ เขาบอกว่ารหัสของเราอยู่คู่กันแน่นเกินไป ตัวอย่างเช่นหากเราต้องการแอพพลิเคชันเดสก์ท็อปเช่นกันเราจะไม่สามารถใช้รหัสที่มีอยู่ของเราได้ วิธีแก้ปัญหาและแนวทางปฏิบัติที่ดีที่สุดที่เขากล่าวคือสร้าง API จากนั้นสร้างเว็บไซต์ของคุณบน API ของคุณจากนั้นสร้างแอปพลิเคชันเดสก์ท็อปแอพมือถือและอื่น ๆ นั้นง่ายมาก ดูเหมือนว่าเป็นความคิดที่ไม่ดีสำหรับฉันด้วยเหตุผลหลายประการ อย่างไรก็ตามฉันไม่สามารถหาสิ่งใดได้โดยใช้ Google ซึ่งอาจพูดถึงการฝึกฝนนี้ ใครบ้างมีข้อมูลเกี่ยวกับข้อดีข้อเสียทำไมคุณควรทำไมคุณไม่ควรหรืออ่านเพิ่มเติม เหตุผลบางอย่างที่ฉันคิดว่ามันเป็นความคิดที่ไม่ดี: มันเป็นนามธรรมเกินไปที่จะเรียกใช้แบ็กเอนด์ของคุณจาก API คุณกำลังพยายามทำให้ยืดหยุ่นเกินไปซึ่งจะทำให้ไม่สามารถจัดการได้ ทุกสิ่งที่สร้างขึ้นใน MVC ดูเหมือนไร้ประโยชน์เช่นบทบาทและการรับรองความถูกต้อง ตัวอย่างเช่น [อนุญาต] คุณสมบัติและความปลอดภัย; คุณจะต้องม้วนตัวเอง การเรียก API ทั้งหมดของคุณจะต้องมีข้อมูลความปลอดภัยแนบมาและคุณจะต้องพัฒนาระบบโทเค็นและอะไรก็ตาม คุณจะต้องเขียนการเรียก API ที่สมบูรณ์สำหรับทุกฟังก์ชั่นเดียวที่โปรแกรมของคุณจะทำ …

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

7
การค้นหาเหมาะสมกับอินเทอร์เฟซ RESTful อย่างไร
เมื่อออกแบบอินเตอร์เฟส RESTful ซีแมนทิกส์ของประเภทคำขอจะถือว่ามีความสำคัญต่อการออกแบบ GET - รายการคอลเลกชันหรือดึงองค์ประกอบ PUT - แทนที่คอลเลกชันหรือองค์ประกอบ POST - สร้างคอลเล็กชันหรือองค์ประกอบ DELETE - เอออืมลบคอลเลกชันหรือองค์ประกอบ อย่างไรก็ตามสิ่งนี้ดูเหมือนจะไม่ครอบคลุมแนวคิดของ "การค้นหา" เช่นในการออกแบบชุดบริการเว็บที่สนับสนุนไซต์หางานคุณอาจมีข้อกำหนดต่อไปนี้: รับโฆษณางานบุคคล รับไปdomain/Job/{id}/ สร้างงานโฆษณา โพสต์ถึงdomain/Job/ อัปเดตงานโฆษณา ใส่ลงไปdomain/Job/ ลบโฆษณางาน ลบไปที่domain/Job/ "รับงานทั้งหมด" ก็ง่าย: รับไปdomain/Jobs/ อย่างไรก็ตามงาน "การค้นหา" ตกอยู่ในโครงสร้างนี้อย่างไร คุณสามารถอ้างว่าเป็น "รูปแบบรายการ" และใช้เป็น: รับไปdomain/Jobs/ อย่างไรก็ตามการค้นหาอาจซับซ้อนและเป็นไปได้ทั้งหมดในการสร้างการค้นหาที่สร้างสตริง GET ที่ยาว นั่นคือการอ้างอิงคำถาม SO ที่นี่มีปัญหาในการใช้สตริง GET ที่มีความยาวมากกว่า 2000 ตัวอักษร ตัวอย่างอาจอยู่ในการค้นหาแบบเหลี่ยมเพชรพลอย - ดำเนินการต่อตัวอย่าง "job" …

14
วิธีการแก้ปัญหาควรเป็นทั่วไปที่สุดหรือเฉพาะเจาะจงที่สุด
สมมติว่าฉันมีเอนทิตีที่มีแอตทริบิวต์ "ประเภท" อาจมีประเภทที่เป็นไปได้มากกว่า 20 รายการ ตอนนี้ฉันขอให้ใช้สิ่งที่จะอนุญาตให้เปลี่ยนประเภทจาก A-> B ซึ่งเป็นกรณีการใช้งานเท่านั้น ดังนั้นฉันควรใช้สิ่งที่อนุญาตให้มีการเปลี่ยนแปลงประเภทโดยพลการตราบเท่าที่พวกเขาเป็นประเภทที่ถูกต้อง? หรือฉันควรอนุญาตให้เปลี่ยนจาก A-> B ตามความต้องการและปฏิเสธการเปลี่ยนแปลงประเภทอื่นเช่น B-> A หรือ A-> C ฉันเห็นข้อดีและข้อเสียของทั้งสองฝ่ายซึ่งวิธีการแก้ปัญหาทั่วไปจะหมายถึงการทำงานน้อยลงในกรณีที่ความต้องการที่คล้ายกันเกิดขึ้นในอนาคต แต่มันก็หมายถึงโอกาสที่จะผิดพลาดมากขึ้น (แม้ว่าเราจะควบคุมผู้โทร 100% จุด). วิธีแก้ปัญหาเฉพาะนั้นมีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยลง แต่ต้องการงานมากขึ้นในอนาคตหากมีข้อกำหนดที่คล้ายกันเกิดขึ้น ฉันได้ยินมาว่านักพัฒนาที่ดีควรพยายามคาดการณ์การเปลี่ยนแปลงและออกแบบระบบเพื่อให้สามารถขยายได้ง่ายในอนาคตซึ่งดูเหมือนว่าโซลูชันทั่วไปเป็นหนทางไปสู่อะไร แก้ไข: การเพิ่มรายละเอียดเพิ่มเติมในตัวอย่างที่ไม่เฉพาะของฉัน: โซลูชัน "ทั่วไป" ในกรณีนี้ต้องใช้งานน้อยกว่าโซลูชัน "เฉพาะ" เนื่องจากโซลูชันเฉพาะต้องมีการตรวจสอบความถูกต้องกับประเภทเก่าและชนิดใหม่ในขณะที่โซลูชันทั่วไป จะต้องตรวจสอบประเภทใหม่เท่านั้น

5
ฉันควรส่งคืนสถานะ HTTP 400 (คำขอไม่ถูกต้อง) หากพารามิเตอร์ถูกต้องทางไวยากรณ์ แต่ละเมิดกฎทางธุรกิจหรือไม่
บอกว่าฉันมีปลายทาง REST ที่ใช้จำนวนเต็มเป็นพารามิเตอร์: /makeWaffles?numberOfWaffles=3 ในกรณีนี้ฉันต้องการให้ตัวเลขเป็นบวกเพราะฉันไม่สามารถลบจำนวนวาฟเฟิลได้ (และการขอ 0 วาฟเฟิลเป็นการเสียเวลา) ดังนั้นฉันต้องการปฏิเสธคำขอใด ๆ ที่ไม่มีจำนวนเต็มบวก ฉันต้องการปฏิเสธคำขอที่มีจำนวนเต็มที่เกินจำนวนสูงสุด (สมมติว่าเป็น MAX_INTEGER) ในกรณีที่มีคนขอวาฟเฟิลในจำนวนที่ไม่เป็นบวกฉันควรส่งคืนสถานะ HTTP 400 (คำขอไม่ถูกต้อง) หรือไม่ ความคิดเริ่มต้นของฉันคือใช่: ไม่ใช่หมายเลขที่ถูกต้องสำหรับฉันที่จะทำตามคำขอ อย่างไรก็ตามRFCไม่ได้กล่าวถึงกฎเกณฑ์ทางธุรกิจว่าเป็นเหตุผลในการ: รหัสสถานะ 400 (คำขอไม่ถูกต้อง) บ่งชี้ว่าเซิร์ฟเวอร์ไม่สามารถหรือไม่สามารถประมวลผลคำขอเนื่องจากสิ่งที่ถูกมองว่าเป็นข้อผิดพลาดของลูกค้า (เช่นไวยากรณ์คำขอที่ผิดรูปแบบ, กรอบข้อความคำขอที่ไม่ถูกต้องหรือการกำหนดเส้นทางคำขอหลอกลวง) กฎทางธุรกิจไม่ได้อยู่ภายใต้ตัวอย่างใด ๆ มันถูกต้องทางไวยากรณ์มีการวางกรอบอย่างเหมาะสมและไม่ได้กำหนดเส้นทางคำขอที่หลอกลวง ดังนั้นฉันควรคืนสถานะ HTTP 400 (คำขอไม่ถูกต้อง) หากพารามิเตอร์ถูกต้องทางไวยากรณ์ แต่ละเมิดกฎทางธุรกิจหรือไม่ หรือมีสถานะที่เหมาะสมกว่าที่จะกลับมา?
56 api-design  http 

9
คุณควรป้องกันค่าที่ไม่คาดคิดจาก API ภายนอกหรือไม่
ช่วยบอกว่าคุณมีการเข้ารหัสฟังก์ชั่นที่ต้องใช้ข้อมูลจาก MyAPIAPI ที่ภายนอก ที่ภายนอก API MyAPIมีสัญญาที่ระบุว่ามันจะกลับมาได้หรือstringnumber มันคือการแนะนำเพื่อป้องกันสิ่งที่ชอบnull, undefined, booleanฯลฯ แม้ว่ามันจะไม่ได้เป็นส่วนหนึ่งของ API ของMyAPI? โดยเฉพาะอย่างยิ่งเนื่องจากคุณไม่สามารถควบคุม API นั้นคุณไม่สามารถรับประกันผ่านการวิเคราะห์ประเภทแบบคงที่ดังนั้นจะปลอดภัยกว่าขออภัยหรือไม่ ฉันกำลังคิดเกี่ยวกับหลักการความแข็งแกร่ง

10
รหัสสถานะ http สำหรับข้อผิดพลาด“ บริการไม่พร้อมให้บริการในพื้นที่ของคุณ” ควรเป็นอย่างไร
บริการของเราอยู่ใน 5 เมืองในขณะนี้ หากมีคนพยายามโทรหา API บริการของเราจากเมืองอื่นเราต้องการส่งข้อผิดพลาดService not available in your areaนี้ คำถามคือรหัส http ที่เหมาะสมสำหรับข้อผิดพลาดนี้คืออะไร? 503: บริการไม่พร้อมใช้งาน 403: ถูกห้าม หรืออย่างอื่น?
51 api  api-design  http 

14
การออกแบบ RESTful API ฉันจะกลับมาได้อย่างไรหากไม่มีแถว?
ขณะนี้ฉันกำลังเขียนรหัส API สำหรับเครือข่ายสังคมด้วย Slim Framework คำถามของฉันคืออะไรแนวปฏิบัติที่ดีที่สุดเมื่อไม่มีแถวที่จะส่งคืนในโครงสร้าง json คืออะไร ให้บอกว่าการโทรนี้/ v1 / get / ภาพยนตร์ส่งคืน 2 แถวจากชื่อภาพยนตร์ตาราง: [ {"name": "Ghostbusters"}, {"name": "Indiana Jones"} ] แต่ฉันโทรหา/ v1 / get / หนังสือและไม่มีแถวในตารางนั้น ฉันควรคืนโครงสร้างว่างเปล่าไหม [ ] ... หรือว่าจะเป็นข้อความและรหัสข้อผิดพลาดดีกว่า [ "errors": { "message": "no matches found", "code": 134 } ] ข้อปฏิบัติที่ดีกว่าคืออะไร (API จะใช้ในแอพ iOS และ …

6
คำขอขนาดเล็กจำนวนมากเทียบกับคำขอขนาดใหญ่จำนวนน้อย (การออกแบบ API)
ฉันกำลังทำงานในโครงการกับองค์กรดังต่อไปนี้: ไคลเอ็นต์ - รับข้อมูลจากเซิร์ฟเวอร์หลักผ่าน REST api เซิร์ฟเวอร์ - ร้องขอข้อมูลจากเซิร์ฟเวอร์อื่น ๆ ผ่าน API ของบุคคลที่สาม API ของบุคคลที่สาม - บริการอยู่นอกเหนือการควบคุมของฉันที่ให้ข้อมูลกับเซิร์ฟเวอร์ (Reddit, Hackernews, Quora ฯลฯ ) เพื่อประโยชน์ในการโต้แย้งสมมติว่าลูกค้าต้องการรายการจาก API บุคคลที่สามแต่ละรายการก่อน จากรายการนี้รายการจะถูกเลือก ณ จุดที่ลูกค้าต้องการดูเนื้อหาทั้งหมดของรายการรวมถึงการตอบกลับ (เช่นความคิดเห็น) ไปยังรายการ ฉันพยายามตัดสินใจระหว่างสามตัวเลือก: อาหารตามสั่ง ในวิธีการนี้ฉันจะมีจุดสิ้นสุด 3 จุดแยกกันบนเซิร์ฟเวอร์ของฉัน: รายการหนึ่งเพื่อรับรายการรายการหนึ่งรายการเพื่อรับเนื้อหาหลักสำหรับรายการและอีกรายการหนึ่งเพื่อรับการตอบกลับของรายการ ข้อดี: ฉันไม่เคยขอมากกว่าที่ต้องการการร้องขอควรมีขนาดเล็กดังนั้นโดยทั่วไปพวกเขาควรจะเร็วกว่า ข้อด้อย: ฉันต้องขอจำนวนมาก หลังจากเลือกรายการจากรายการผู้ใช้อาจต้องรอก่อนเห็นเนื้อหาหลักจากนั้นรออีกนานเพื่อดูการตอบกลับ แคชฝั่งเซิร์ฟเวอร์ ในคำขอนี้ฉันจะโทรหาเซิร์ฟเวอร์ของฉันเพื่อ "ดึง" ข้อมูลทั้งหมดสำหรับแหล่งที่มาทั้งหมด ข้อมูลจะถูกแคชบนเซิร์ฟเวอร์ จากนั้นไคลเอ็นต์จะมีจุดสิ้นสุด REST แบบเดิมเหมือนกันยกเว้นจะไม่มีการรอระหว่างการโทรเนื่องจากเซิร์ฟเวอร์ของฉันมีข้อมูลอยู่แล้วและจะต้องป้อนให้กับลูกค้า ข้อดี: …

3
ทำไม PATCH ถึงไม่เป็น idempotent?
ฉันสงสัยเกี่ยวกับเรื่องนี้ สมมติว่าฉันมีuserทรัพยากรด้วยidและnameสาขา ถ้าฉันต้องการอัปเดตฟิลด์ฉันสามารถทำคำขอแพทช์กับทรัพยากรเช่นนี้ได้ PATCH /users/42 {"name": "john doe"} จากนั้นแอปพลิเคชันจะอัปเดตชื่อผู้ใช้ 42 แต่ทำไมถ้าฉันทำซ้ำคำขอนี้ผลลัพธ์จะแตกต่างกันอย่างไร อ้างอิงจากRFC 5789 PATCH นั้นไม่ปลอดภัยหรือ idempotent

6
จำเป็นหรือไม่ที่จะต้องปฏิบัติตามแนวทางการเขียนโปรแกรมเชิงป้องกันสำหรับโค้ดที่จะไม่เปิดเผยต่อสาธารณะ
ฉันกำลังเขียนการนำเกมจาวามาใช้ในเกมไพ่ดังนั้นฉันจึงสร้างคอลเลกชันชนิดพิเศษที่ฉันเรียกว่าโซน วิธีการปรับเปลี่ยนทั้งหมดของคอลเลกชันของ Java ไม่ได้รับการสนับสนุน แต่มีวิธีการใน Zone API move(Zone, Card)ซึ่งย้ายการ์ดจากโซนที่กำหนดไปยังตัวมันเอง (สำเร็จโดยเทคนิคแพคเกจส่วนตัว) ด้วยวิธีนี้ฉันสามารถมั่นใจได้ว่าไม่มีไพ่ถูกนำออกจากโซนและหายตัวไป สามารถย้ายไปยังโซนอื่นได้เท่านั้น คำถามของฉันคือการเข้ารหัสป้องกันแบบนี้มีความจำเป็นมากแค่ไหน? มัน "ถูกต้อง" และรู้สึกเหมือนถูกวิธี แต่ไม่ใช่ว่า Zone API จะเป็นส่วนหนึ่งของห้องสมุดสาธารณะ มันเป็นเพียงสำหรับฉันดังนั้นมันเหมือนกับว่าฉันกำลังปกป้องรหัสของฉันจากตัวเองเมื่อฉันอาจจะมีประสิทธิภาพมากขึ้นโดยเพียงแค่ใช้คอลเลกชันมาตรฐาน ฉันควรใช้ความคิดโซนนี้ไกลแค่ไหน ใครบ้างที่สามารถให้คำแนะนำกับฉันเกี่ยวกับการรักษาสัญญาในชั้นเรียนที่ฉันเขียนโดยเฉพาะอย่างยิ่งสำหรับคนที่ไม่ได้เผยแพร่สู่สาธารณะ

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

8
ทำไม java.util.ArrayList อนุญาตให้เพิ่ม null?
ผมสงสัยว่าทำไมช่วยให้การเพิ่มjava.util.ArrayList nullมีกรณีใดที่ฉันต้องการที่จะเพิ่มnullไปยังArrayList? ฉันถามคำถามนี้เพราะในโครงการเรามีข้อผิดพลาดที่มีการเพิ่มรหัสบางส่วนnullลงไปArrayListและมันก็ยากที่จะทราบว่าจุดบกพร่องนั้นอยู่ที่ไหน เห็นได้ชัดว่าNullPointerExceptionถูกโยน แต่ไม่จนกว่ารหัสอื่นพยายามเข้าถึงองค์ประกอบ ปัญหาคือวิธีการค้นหารหัสที่เพิ่มnullวัตถุ มันจะง่ายกว่านี้หากArrayListมีข้อยกเว้นในรหัสที่มีการเพิ่มองค์ประกอบ

1
null เทียบกับคีย์ที่ขาดหายไปในการตอบสนอง REST API [ปิด]
พูดในแอปพลิเคชันของฉันผู้ใช้บางรายให้นามสกุลกับเรา ในการตอบสนอง REST API ร่างกายที่ต้องการ: ด้วยค่า "null": {"firstName": "Bob", "lastName": null} หรือคีย์ที่หายไป: {"firstName": "Bob"}
40 rest  api-design  json 

11
REST API ควรส่งคืนข้อผิดพลาดเซิร์ฟเวอร์ภายใน 500 ข้อเพื่อระบุว่าแบบสอบถามอ้างอิงวัตถุที่ไม่มีอยู่หรือไม่
ฉันกำลังทำงานกับ REST API ซึ่งอยู่บนเซิร์ฟเวอร์ที่จัดการข้อมูลสำหรับอุปกรณ์ IoT จำนวนมาก งานของฉันคือการสืบค้นเซิร์ฟเวอร์โดยใช้ API เพื่อรวบรวมข้อมูลประสิทธิภาพเฉพาะเกี่ยวกับอุปกรณ์ดังกล่าว ในอินสแตนซ์หนึ่งฉันได้รับรายการอุปกรณ์ที่มีอยู่และตัวระบุที่เกี่ยวข้องจากนั้นจึงสอบถามเซิร์ฟเวอร์เพื่อรับรายละเอียดเพิ่มเติมโดยใช้ตัวระบุเหล่านั้น (GUID) เซิร์ฟเวอร์ส่งคืน500 Internal Server Errorแบบสอบถามสำหรับหนึ่งใน ID เหล่านั้น ในแอปพลิเคชันของฉันมีข้อผิดพลาดเกิดขึ้นและฉันไม่เห็นรายละเอียดเกี่ยวกับข้อผิดพลาด หากฉันตรวจสอบการตอบสนองอย่างใกล้ชิดกับบุรุษไปรษณีย์ฉันจะเห็นว่าเซิร์ฟเวอร์ส่งคืน JSON ในเนื้อหาซึ่งมี: errorMessage: "This ID does not exist". ไม่สนใจข้อเท็จจริงที่เซิร์ฟเวอร์ระบุรหัสเริ่มต้นนั่นเป็นปัญหาแยกต่างหากสำหรับนักพัฒนา REST API ควรส่งคืน a 500 Internal Server Errorเพื่อรายงานว่าแบบสอบถามอ้างอิงวัตถุที่ไม่มีอยู่หรือไม่? ตามความคิดของฉันรหัสตอบกลับ HTTP ควรอ้างอิงอย่างเคร่งครัดถึงสถานะของการเรียกใช้ REST แทนที่จะใช้กลไกภายในของ API ฉันคาดหวังว่าจะ200 OKมีการตอบสนองที่มีข้อผิดพลาดและคำอธิบายซึ่งจะเป็นกรรมสิทธิ์ของ API ที่เป็นปัญหา มันเกิดขึ้นกับฉันว่ามีความคาดหวังที่แตกต่างกันขึ้นอยู่กับว่าการเรียกใช้ REST นั้นมีโครงสร้างอย่างไร ลองพิจารณาตัวอย่างเหล่านี้: …

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