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

เรามีฟังก์ชัน API ที่แบ่งจำนวนเงินทั้งหมดเป็นจำนวนเงินรายเดือนตามวันที่เริ่มต้นและวันที่สิ้นสุดที่กำหนด // JavaScript function convertToMonths(timePeriod) { // ... returns the given time period converted to months } function getPaymentBreakdown(total, startDate, endDate) { const numMonths = convertToMonths(endDate - startDate); return { numMonths, monthlyPayment: total / numMonths, }; } เมื่อเร็ว ๆ นี้ผู้บริโภคสำหรับ API นี้ต้องการระบุช่วงวันที่ด้วยวิธีอื่น: 1) โดยระบุจำนวนเดือนแทนที่จะเป็นวันที่สิ้นสุดหรือ 2) โดยระบุการชำระเงินรายเดือนและการคำนวณวันที่สิ้นสุด เพื่อตอบสนองต่อสิ่งนี้ทีม API …

38 api-design 

ฉันเสนอการเปลี่ยนแปลงโครงการซอฟต์แวร์ที่ได้รับการออกแบบมาไม่ดีนักซึ่งมีปัญหามากมาย ในระดับสูงโครงการใช้ Angular บน front-end และใช้ REST APIs ต่างๆ ซึ่งเป็นสิ่งที่ยอดเยี่ยม (ฉันไม่เห็นความจำเป็นในการเปลี่ยนแปลงเทคโนโลยีหรือเครื่องมือของเรา) ปัญหาคือรหัสฐานมีขนาดใหญ่กว่าใน API มากกว่าฝั่งเซิร์ฟเวอร์ ตรรกะทางธุรกิจส่วนใหญ่อาศัยอยู่ใน UI ด้วย REST APIs ที่เป็นอินเตอร์เฟสฐานข้อมูล CRUD อย่างง่ายไปยังเลเยอร์ UI ตัวอย่างเช่น POST ให้กับลูกค้าจะสร้างระเบียนลูกค้าในขณะที่ PUT จะแก้ไขลูกค้ารายนั้น ไม่มากและไม่มากน้อย อย่างไรก็ตามตรรกะทางธุรกิจของเรานั้นมีความต้องการมากกว่านั้น กระบวนการทั่วไปในการสร้างลูกค้านั้นค่อนข้างมากกว่าการแทรก 1 บันทึกฐานข้อมูล มันจะจัดเตรียมข้อมูลในตารางที่จำเป็นอื่น ๆ ทำการตรวจสอบความถูกต้องและการคำนวณบางอย่าง ฯลฯ ฉันต้องการทำการเรียก POST / PUT หนึ่งครั้งเพื่อสรุปพฤติกรรมทั้งหมดนี้เพื่อลดภาระของลูกค้าที่บริโภค ดังนั้นมุมมองของฉันคือว่า orchestration ที่ครอบคลุมนี้ควรมีชีวิตอยู่บนเซิร์ฟเวอร์ (ที่เรามีการควบคุมเต็มรูปแบบบันทึก ฯลฯ ) ไม่ใช่ UI …

37 rest  api-design  enterprise-architecture 

เมื่อพูดถึง API ของ JSON เป็นวิธีปฏิบัติที่ดีในการแผ่การตอบสนองออกและหลีกเลี่ยงวัตถุ JSON ที่ซ้อนกันหรือไม่ ตัวอย่างเช่นสมมติว่าเรามี API คล้ายกับ IMDb แต่สำหรับวิดีโอเกม มีหน่วยงานคู่เกมแพลตฟอร์ม ESRBRating และ GamePlatformMap ซึ่งทำแผนที่เกมและแพลตฟอร์ม สมมติว่าคุณร้องขอ / เกม / 1 ซึ่งดึงข้อมูลเกมด้วย ID 1 และส่งคืนออบเจ็กต์เกมด้วยแพลตฟอร์มและการซ้อนทับซ้อน { "id": 1, "title": "Game A", "publisher": "Publisher ABC", "developer": "Developer DEF", "releaseDate": "2015-01-01", "platforms": [ {"id":1,"name":"Xbox"}, {"id":2,"name":"Playstation"} ], "esrbRating": { "id": 1, "code": …

37 design  rest  api-design  json 

มีมาตรฐานบางอย่างเกี่ยวกับการตอบกลับ HTTP API หรือไม่ หลังจากอ่านหัวข้อสนทนานี้ฉันเริ่มสงสัย เรากำลังพัฒนา HTTP JSON API สาธารณะของเราในที่ทำงานของฉันและเราจะไม่ส่งคืนสิ่งใดเมื่อไม่จำเป็นอย่างเคร่งครัด (เช่น PUT to / resource / {id} เท่านั้นส่งคืน 200 เมื่อตกลงหรือรหัส 4XX หรือ 5XX ที่เกี่ยวข้อง แต่ไม่ ร่างกาย JSON) เราควรคืนค่าตัวแบบทั่วไป{"success":true}เช่นที่พวกเขาพูดคุยเกี่ยวกับลิงก์ข้างต้นหรือไม่มันก็โอเคที่จะคืนค่าส่วน "โมฆะ" และจัดการทุกอย่างด้วยรหัสตอบกลับ http?

33 rest  api-design  http 

ในการอภิปรายเกี่ยวกับวิธีการแบบคงที่และอินสแตนซ์ฉันคิดเสมอว่าSqrt()ควรเป็นวิธีการแบบอินสแตนซ์ของชนิดตัวเลขแทนวิธีแบบคงที่ ทำไมถึงเป็นอย่างนั้น? เห็นได้ชัดว่ามันทำงานกับค่า // looks wrong to me var y = Math.Sqrt(x); // looks better to me var y = x.Sqrt(); ToString()ชนิดของมูลค่าชัดสามารถมีวิธีการเช่นเดียวกับในหลายภาษามีวิธีการเช่น เพื่อตอบคำถามจากความคิดเห็น: ทำไม1.Sqrt()ไม่ควรถูกกฎหมาย? 1.ToString()คือ. บางภาษาไม่อนุญาตให้มีวิธีการในประเภทค่า แต่บางภาษาสามารถ ฉันกำลังพูดถึงสิ่งเหล่านี้รวมถึง Java, ECMAScript, C # และ Python (พร้อมคำ__str__(self)จำกัดความ) เช่นเดียวกับฟังก์ชั่นอื่น ๆ เช่นceil(), floor()ฯลฯ

31 programming-languages  language-design  history  api-design  math 

ฉันออกแบบแอปพลิเคชันด้วยบริการไมโครและฉันไม่แน่ใจเกี่ยวกับกลไกที่ดีที่สุดที่จะใช้ในการรวบรวมข้อมูลจากบริการที่หลากหลาย ฉันเชื่อว่ามีสองตัวเลือก: บูรณาการกลไกการสื่อสาร 'บริการระหว่าง' ที่ช่วยให้บริการที่จะพูดคุยโดยตรง API เกตเวย์จะเรียกใช้บริการส่วนบุคคลซึ่งจะเรียกบริการอื่น ๆ เพื่อรวบรวมข้อมูลก่อนส่งคืนการตอบกลับแบบรวมไปยัง API เกตเวย์ จากนั้น API จะส่งคืนการตอบกลับไปยังผู้โทร (สิ่งนี้จะต้องเป็นการโทรแบบซิงโครนัสเมื่อการเรียกใช้บริการ serviceB ต้องการการตอบสนองจาก serviceA. IE แยกคนและบริการที่อยู่) ให้ API เกตเวย์โทรไปยังแต่ละบริการโดยตรงและรวบรวมข้อมูลภายใน API ก่อนที่จะตอบกลับ ฉันเอนตัวไปสู่ทางเลือกที่สองเนื่องจากการให้บริการพูดคุยกันจะแนะนำการมีเพศสัมพันธ์ซึ่งในกรณีนี้ฉันก็อาจสร้างแอพพลิเคชั่นแบบเสาหิน อย่างไรก็ตามมีข้อเสียร้ายแรงบางประการที่ฉันสามารถคิดได้จากส่วนหัวของฉันด้วยตัวเลือกนี้: การให้ API ดำเนินการเรียกหลายครั้งไปยังหลายบริการจะช่วยเพิ่มภาระให้กับเซิร์ฟเวอร์ API โดยเฉพาะอย่างยิ่งเมื่อการโทรบางส่วนกำลังปิดกั้น วิธีนี้จะหมายความว่า API จะต้อง 'ตระหนักถึง' สิ่งที่แอปพลิเคชันพยายามทำ (IE Logic จะต้องถูกตั้งโปรแกรมไว้ใน API เพื่อจัดการกับการเรียกใช้บริการในทางกลับกันและรวมข้อมูลแล้ว) ทำหน้าที่เป็น 'ปลายทาง' โง่สำหรับบริการไมโคร ฉันต้องการทราบว่าแนวทางมาตรฐานสำหรับปัญหานี้คืออะไรและหากมีตัวเลือกที่สามที่ฉันพลาด

30 architecture  api-design  microservices 

ฉันกำลังประเมินห้องสมุดซึ่งปัจจุบัน API สาธารณะมีลักษณะเช่นนี้: libengine.h /* Handle, used for all APIs */ typedef size_t enh; /* Create new engine instance; result returned in handle */ int en_open(int mode, enh *handle); /* Start an engine */ int en_start(enh handle); /* Add a new hook to the engine; hook handle returned in h2 …

27 c  api-design  libraries 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่ผ่านมา ฉันต้องจองชื่อผู้ใช้ในเว็บไซต์ใหม่ของฉัน โดยทั่วไปแล้วแบ่งออกเป็นสามประเภท 1) ชื่อผู้ใช้ที่ไม่ควรมี (เช่น: ผู้ดูแลระบบผู้ใช้บริการความช่วยเหลือรูตและอื่น ๆ ) 2) ชื่อของบุคคลหรือ บริษัท ที่มีชื่อเสียงระดับสูงที่เราอาจต้องการจองในกรณีที่ปรากฏ 3) ชื่ออื่นที่ระบุโดยเราโดยตรง มันจะมีประโยชน์จริง ๆ ถ้ามีรายชื่อผู้ใช้สำหรับ 2 หมวดหมู่แรกที่มีอยู่และฉันสามารถใช้มันได้ ไม่มีใครรู้รายการดังกล่าวหรือไม่

26 database  design  data  api-design 

ฉันกำลังพิจารณาที่จะย้าย REST API แบบเสาหินไปยังสถาปัตยกรรม microservice และฉันสับสนเล็กน้อยเกี่ยวกับที่เก็บข้อมูล ตามที่ฉันเห็นประโยชน์บางประการของ microservices คือ: ปรับขนาดได้ในแนวนอน - ฉันสามารถเรียกใช้สำเนาบริการซ้ำซ้อนหลายชุดเพื่อจัดการกับโหลดและ / หรือเซิร์ฟเวอร์หยุดทำงาน การเชื่อมโยงอย่างหลวม - ฉันสามารถเปลี่ยนการใช้งานภายในของไมโครไซต์โดยไม่ต้องเปลี่ยนไมโครซอฟท์และฉันสามารถปรับใช้และเปลี่ยนแปลงได้อย่างอิสระ ... ปัญหาของฉันอยู่ที่การจัดเก็บข้อมูล เท่าที่ฉันเห็นมันมีหลายตัวเลือก: บริการฐานข้อมูลเดียวที่ใช้ร่วมกันโดย microservices ทั้งหมด - นี่ดูเหมือนจะขจัดข้อได้เปรียบของการมีเพศสัมพันธ์แบบหลวม ๆ อย่างสมบูรณ์ อินสแตนซ์ฐานข้อมูลที่ติดตั้งในเครื่องบนไมโครไซต์แต่ละบริการ - ฉันไม่เห็นวิธีการปรับขนาดแนวนอนดังนั้นฉันไม่คิดว่ามันจะเป็นตัวเลือก microservice แต่ละตัวมีบริการฐานข้อมูลของตัวเอง - ซึ่งเป็นวิธีที่มีแนวโน้มมากที่สุดเนื่องจากจะรักษาประโยชน์ของข้อต่อหลวมและการขยายตามแนวนอน (โดยใช้สำเนาฐานข้อมูลที่ซ้ำซ้อนและ / หรือทำให้เกิดปัญหาหลายอย่าง) สำหรับฉันตัวเลือกที่สามน่าจะเป็นตัวเลือกเดียว แต่ดูเหมือนว่าฉันจะมีน้ำหนักมากอย่างไม่น่าเชื่อและเป็นวิธีแก้ปัญหาที่มีการปรับแก้มากเกินไป ถ้าฉันเข้าใจถูกต้องแล้วสำหรับแอปพลิเคชันธรรมดาที่มี 4-5 microservices ฉันต้องใช้เซิร์ฟเวอร์ 16-20 - สองอินสแตนซ์ microservice จริงสองต่อ microservice (ในกรณีที่เซิร์ฟเวอร์ล้มเหลวและสำหรับการปรับใช้โดยไม่ต้องหยุดทำงาน) …

25 architecture  rest  api-design  microservices 

ในขณะที่สร้างRESTful APIฉันควรใช้ HTTP Verbs บน URL เดียวกัน (เมื่อเป็นไปได้) หรือฉันควรสร้าง URL เฉพาะสำหรับแต่ละการกระทำ ตัวอย่างเช่น: GET /items # Read all items GET /items/:id # Read one item POST /items # Create a new item PUT /items/:id # Update one item DELETE /items/:id # Delete one item หรือด้วย URL เฉพาะเช่น: GET /items # Read …

25 rest  api-design  web-api 

เมื่อพูดคุยเกี่ยวกับ API ระหว่างระบบ (ในระดับธุรกิจ) มักจะมีมุมมองที่แตกต่างกันสองประการในทีมของเรา: บางคนชอบมากกว่า - ให้พูดว่า - วิธีนามธรรมทั่วไป ตัวอย่าง: การออกแบบ API ค้นหา "บุคคล" แบบง่าย รุ่นที่เป็นรูปธรรมจะเป็น searchPerson(String name, boolean soundEx, String firstName, boolean soundEx, String dateOfBirth) คนที่ชื่นชอบเวอร์ชั่นคอนกรีตพูดว่า: API คือการจัดทำเอกสารด้วยตนเอง มันง่ายที่จะเข้าใจ มันง่ายต่อการตรวจสอบ (คอมไพเลอร์หรือเป็นเว็บเซอร์: การตรวจสอบสคีมา) จูบ กลุ่มคนอื่น ๆ ในทีมของเราจะพูดว่า "นั่นเป็นเพียงรายการของเกณฑ์การค้นหา" searchPerson(List<SearchCriteria> criteria) กับ SearchCritera { String parameter, String value, Map<String, String> …

25 api  web-services  api-design 

ในโครงการปัจจุบันของฉันฉันรับผิดชอบการใช้งานบริการที่เกี่ยวข้องกับการใช้ RESTful APIs ที่สร้างขึ้นใหม่ซึ่งบันทึกไว้ว่ารองรับ JSON เท่านั้น ลูกค้าทำการร้องขออย่างต่อเนื่องโดยมีส่วนหัวการยอมรับของ 'application / json' และประเภทเนื้อหาของ 'application / json' อย่างไรก็ตามปลายทางบางจุดส่งการตอบกลับด้วย HTML ชนิดเนื้อหาหรือแม้แต่เนื้อหา HTML สำหรับฉันนี่เป็นแนวทางที่ผิดอย่างชัดเจนและไม่สามารถพิสูจน์ได้ ตลอดโครงการนี้มีการใช้วิธีปฏิบัติเดียวกันนี้กับผู้ขายที่ต่างกันสองรายและบริการที่แตกต่างกันสองรายการ ฉันพบว่าตัวเองต้องพิสูจน์เหตุผลที่บริการที่จำเป็นต้องมีการเปลี่ยนแปลง ผู้ขายระบุว่าลูกค้าควรรับมือกับสิ่งนี้และแม้แต่ห้องสมุด REST ที่ฉันเลือกก็ถูกตั้งคำถาม (RestEasy) เพราะไม่ได้จัดการกับสิ่งนี้ตามค่าเริ่มต้น 'นอกกรอบ' นี่เป็นจุดสำคัญของความยุ่งยาก ฉันไม่พบการอ้างอิงจำนวนมากเพื่อสำรองอาร์กิวเมนต์ของฉันฉันคิดว่านี่เป็นเพราะประเด็นนั้นเป็นที่สงสัยเนื่องจากมันชัดเจนมาก คำถามคือฉันหายไปบางอย่าง? ฉันเป็นคนหยาบคายเกี่ยวกับเรื่องนี้หรือไม่? ตกลงหรือไม่ที่จะมี JSON API ที่ไม่มีประเภทแอปพลิเคชัน / json ในสถานการณ์นี้ การอ้างอิงจะได้รับการชื่นชม คุณจะแก้ไขสถานการณ์นี้จากมุมมองทางการค้าได้อย่างไร

25 rest  api-design  json  bad-code 

ฉันมีแพลตฟอร์มรางที่ฉันบำรุงรักษา มันมีเว็บแอปพลิเคชั่นที่แตกต่างกันมากมาย อย่างไรก็ตามตอนนี้ลูกค้ากำลังขอ API เพื่อให้พวกเขาสามารถเก็บผู้ใช้ในเว็บไซต์ของพวกเขา แต่ใช้ประโยชน์จากงานอัตโนมัติบางอย่างที่เรามี แพลตฟอร์มดังกล่าวใช้เพื่อสร้างแอปพลิเคชั่นประกันภัยและอนุญาตให้ซื้อสินค้าทางออนไลน์รวมถึงวิธีการดาวน์โหลดเอกสารที่เกี่ยวข้องกับนโยบายของคุณ ดังนั้นคำถามของฉันเมื่อสร้าง API คือ: เมื่อฉันต้องทำสิ่งต่างๆมากมายเช่นการvalidateสร้างuser, user profileและpolicyสวยมากในเวลาเดียวกัน ฉันควรทำการโทรแบบแยก 4 ครั้งและให้ลูกค้าสร้างการโทร 4 ครั้งที่ด้านข้าง หรือฉันควรจะมีหนึ่งสายที่ยกเว้นพารามิเตอร์จำนวนมากที่ตรวจสอบลูกค้าและสร้างทั้ง 3 สิ่งในเวลาเดียวกันทำให้สิ่งต่าง ๆ ง่ายขึ้นสำหรับลูกค้า? ในกรณีนี้ลูกค้าจะได้รับข้อมูลที่จำเป็นทั้งหมดในเวลาเดียวกันดังนั้นจึงไม่เหมือนกับว่ามีการไหลตามธรรมชาติในแอปพลิเคชันของพวกเขาที่หยุดชั่วคราวและพวกเขาสามารถเรียก API ไปยังแพลตฟอร์มของฉันได้ ก่อนหน้านี้ลูกค้าเคยใช้ API หลายตัวมาแล้วความกล้าของฉันคือทำให้มันง่ายสำหรับลูกค้าเท่าที่จะทำได้และให้พวกเขาทำการโทรเพียงครั้งเดียว อย่างไรก็ตามสิ่งนี้นำไปสู่ค่อนข้างใหญ่functionsใน API ซึ่งฉันไม่ได้เป็นแฟนของทั้ง คุณจะแนะนำให้ฉันแก้ไขปัญหานี้ได้อย่างไร ตามที่ทราบมาฉันไม่มั่นใจในความสามารถของลูกค้าในการนำ API ที่ซับซ้อนมาใช้

25 web-applications  ruby-on-rails  api-design 

คำถามนี้ถูกโยกย้ายจาก Server Fault เนื่องจากสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 6 ปีที่แล้ว ฉันกำลังใช้ HTTP API เป็นครั้งแรก ฉันใช้เวลาไปกับการดูหน้า Wikipedia สำหรับรหัสสถานะ HTTP เพราะฉันมุ่งมั่นที่จะใช้รหัสที่ถูกต้องสำหรับสถานการณ์ที่เหมาะสม รายชื่อในหน้านั้นเป็นรหัสที่มีหมายเลข 420 ซึ่งเป็นรหัสที่กำหนดเองซึ่ง Twitter ใช้เพื่อ จำกัด อัตรา มีรหัสสำหรับการ จำกัด อัตราอยู่แล้ว มันคือ 429 สิ่งนี้ทำให้ฉันสงสัยว่าทำไมพวกเขาถึงกำหนดเองเมื่อมีกรณีใช้งานอยู่แล้ว นั่นน่ารักใช่มั้ย และหากเป็นเช่นนั้นสถานการณ์ใดบ้างที่จะทำให้ยอมรับรหัสสถานะที่แตกต่างออกไปและสิ่งใดหากลูกค้ามีปัญหาใด ๆ ฉันอ่านที่ไหนสักแห่งที่ Mozilla ไม่ได้ใช้การ418: I’m a teapotตอบสนองตลกซึ่งทำให้ฉันคิดว่าลูกค้าเลือกรหัสสถานะที่พวกเขาใช้ ถ้านั่นเป็นเรื่องจริงฉันก็นึกภาพเล็ก ๆ น้อย ๆ ของ Twitter ที่ทำให้รหัสสงบของคุณเป็นปัญหา นอกจากว่าฉันเข้าใจผิดและเราสามารถใส่หมายเลขรหัสใดก็ได้เพื่อหมายถึงสิ่งที่เราชอบและมีเพียงการประชุมที่บอกว่าไม่พบ …

24 api-design  http 

ฉันออกแบบ REST API สำหรับโครงการที่ผู้ใช้มักจะอยู่ใน "แผน" หนึ่งในหลาย ๆ แผน - แต่ละแผนกำหนดข้อ จำกัด ของทรัพยากรบางอย่างเช่นจำนวนผู้ใช้สูงสุดที่บัญชีอาจมีหรือจำนวนข้อมูลสูงสุดที่พวกเขาอาจอัปโหลด เมื่อถึงขีด จำกัด เหล่านี้ผู้ใช้สามารถอัปเกรดแผนของพวกเขา (จ่ายเป็นหลัก) เพื่อรับทรัพยากรเพิ่มเติม ฉันต้องการส่งคืนรหัสสถานะพิเศษที่ระบุสถานการณ์ที่ไม่สามารถดำเนินการได้เนื่องจากข้อ จำกัด ของทรัพยากรบัญชีและการอัปเกรดแผนจะแก้ไขปัญหานี้ - ตัวอย่างเช่นหากผู้ใช้ใช้ 100% ของความจุในการจัดเก็บและลองอัปโหลดไฟล์เพิ่มเติม พวกเขาจะได้รับคำตอบนี้ ผู้สมัครคือ IMHO: 403 Forbidden - อย่างไรก็ตามฉันต้องการแยกความแตกต่างระหว่างกรณีนี้และกรณีอื่น ๆ ที่ผู้ใช้ขาดสิทธิ์ในการดำเนินการนี้ 401 Unauthorized - ไม่ใช่ความคิดที่ดีเราใช้มันเพื่อตรวจสอบปัญหาที่เกี่ยวข้อง 402 Payment Required - ทำให้รู้สึก แต่ฉันกังวลเกี่ยวกับการใช้รหัสสถานะที่ไม่ได้มาตรฐาน แต่สงวนไว้ บางสิ่งที่เป็นมาตรฐานน้อยลงอย่าง423 Lockedที่ไม่น่าเป็นไปได้เราจะใช้มันเพื่อสิ่งอื่นในอนาคต ตัวเลือกอื่นคือไปกับสิ่งที่มาตรฐานมากเช่น403แต่ระบุเฉพาะข้อผิดพลาดในเนื้อหาการตอบสนอง ฉันสงสัยว่าวิธีการใดที่คุณเชื่อว่า (ก) จะทำงานได้ดีที่สุดในระยะยาวและ …

24 rest  api-design  http