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

application programming interface (API) เป็นข้อกำหนดสำหรับซอฟต์แวร์อื่นที่ใช้กับซอฟต์แวร์อื่น

5
API พิจารณาว่าเป็น DSL ในตัวเมื่อใด
ความแตกต่างระหว่าง API และภาษาเฉพาะโดเมนแบบฝัง (DSL) คืออะไร มันเป็นเพียงไวยากรณ์ พิจารณา API เช่น OpenGL มันแตกต่างจาก DSL กราฟิกอย่างไร กล่าวอีกนัยหนึ่งถ้า API มีความซับซ้อนเพียงพอจะถือว่าเป็น DSL แบบฝังได้หรือไม่
10 api  dsl 

3
มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่สำหรับคำนิยามออบเจ็กต์ API ที่มีรหัสอ้างอิงบุคคลที่สามเป็นคุณสมบัติหรือไม่
แบบนี้: Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" ผมกังวลเกี่ยวกับreferenceid โดเมนระบบเป็นแพลตฟอร์มที่รวมเข้ากับบุคคลที่สามได้หลายวิธีผ่านการส่งออกข้อมูลและการนำเข้ารูปแบบต่างๆ (xml, excel) เป็นผู้ใหญ่พอที่จะอนุญาตให้บุคคลที่ 3 รวมกับระบบของเราผ่าน API และการออกแบบของ …

2
การเพิ่มชุดของตัวเลือกที่ จำกัด ; การแตกหักของ API คืออะไร
ใช้จุดปลาย HTTP API ซึ่งพ่นรูปแบบการตอบสนองต่อไปนี้: { "type": "Dog", "name": "Jessi", ... } typeข้อมูลได้รับการอธิบายไว้ในเอกสารที่เป็นหนึ่งDog, หรือCatFish การเพิ่มตัวเลือกใหม่Ratจะถือว่าเป็นการเปลี่ยนแปลง API ที่ผิดปกติหรือไม่ การเพิ่มตัวเลือกในรายการที่ จำกัด (ซึ่งนักพัฒนาซอฟต์แวร์อาจเปิดใช้งาน) ถือว่าเป็นส่วนขยายหรือการแก้ไข API หรือไม่
9 rest  api  api-design  json 

3
ในการพูดจา REST ความแตกต่างระหว่างทรัพยากรและการเป็นตัวแทนคืออะไร?
ความเข้าใจของฉันเกี่ยวกับ REST ที่เปิดใช้งานการสร้างแบบจำลองการบริการเป็นการแสดงสถานะและการเปลี่ยนจากสถานะหนึ่งไปสู่อีกสถานะหนึ่งทำให้ใช้ HTTP ฉันมักจะเข้าใจแหล่งข้อมูลว่าเป็นตัวแทนของสถานะด้านบริการจนกระทั่งเมื่อไม่นานมานี้เมื่อฉันอ่านบทความนี้โดย Jimmy Bogard ซึ่งฉันรู้ว่าเป็นนักพัฒนา / สถาปนิกที่ชาญฉลาดซึ่งเป็นที่เคารพของชุมชน เพื่ออ้างอิงข้อความเฉพาะจากโพสต์นั้น การเป็นตัวแทนแตกต่างกันเล็กน้อย - มันอธิบายถึง สถานะปัจจุบันของทรัพยากร (เมื่อมีการร้องขอ) นี่ทำให้ฉันสับสน ความคิดเห็นที่ยอมรับโดยทั่วไปในหัวข้อคืออะไร?
9 rest  api  api-design 

2
คำเตือนใน REST API ไม่ใช่ข้อผิดพลาดร้ายแรง
ฉันมี REST API สำหรับ entpoinds บางตัวเช่น DELETE, POST หรือ PUT ฉันมีกฎการตรวจสอบที่สามารถส่งคืนข้อผิดพลาดได้ ตอนนี้ฉันต้องการข้อผิดพลาดชนิดใหม่เช่นข้อผิดพลาดที่ไม่ร้ายแรงว่าควรล้มเหลวในลักษณะปกติ แต่ควรดำเนินการหากมีการส่งแฟล็ก "supress warnings" ผู้ใช้ดังกล่าวสามารถถาม: "คุณแน่ใจหรือว่าต้องการเปลี่ยนสถานะนี้คุณยังไม่เสร็จ" คำถาม : มีวิธีปฏิบัติที่ดีที่สุดสำหรับข้อผิดพลาดประเภทนี้หรือไม่? คำถามรอง : มี HTTP semantic ใด ๆ สำหรับพฤติกรรมที่ฉันสามารถใช้หรือไม่ ฉันจะยังคงทำตามแนวคิด REST (สำหรับฉันแล้วดูเหมือนว่าฉันจะทำ) - ฉันเก็บมันไว้ไร้สัญชาติ
9 rest  api 

3
CRUD API: คุณจะระบุฟิลด์ที่จะอัปเดตได้อย่างไร
สมมติว่าคุณมีโครงสร้างข้อมูลบางประเภทซึ่งยังคงอยู่ในฐานข้อมูลบางประเภท เพื่อความง่ายเราจะเรียกโครงสร้างข้อมูลPersonนี้ ขณะนี้คุณได้รับมอบหมายให้ออกแบบ CRUD API ซึ่งอนุญาตให้แอปพลิเคชันอื่นสร้างอ่านอัปเดตและลบPersons เพื่อความง่ายลองสมมติว่า API นี้เข้าถึงได้ผ่านบริการเว็บบางประเภท สำหรับชิ้นส่วน C, R และ D ของ CRUD การออกแบบนั้นง่าย ฉันจะใช้เครื่องหมายคล้ายฟังก์ชัน C # - การใช้งานอาจเป็น SOAP, REST / JSON หรืออย่างอื่น: class Person { string Name; DateTime? DateOfBirth; ... } Identifier CreatePerson(Person); Person GetPerson(Identifier); void DeletePerson(Identifier); แล้วการอัพเดตล่ะ? สิ่งที่ต้องทำตามธรรมชาติคือ void UpdatePerson(Identifier, Person); แต่วิธีการที่คุณจะต้องระบุให้ซึ่งด้านของPersonการอัปเดต? วิธีแก้ปัญหาที่ฉันสามารถทำได้: คุณสามารถกำหนดให้บุคคลที่สมบูรณ์ต้องผ่านเช่นลูกค้าจะทำสิ่งนี้เพื่ออัปเดตวันเกิด: …

3
ใช้ PUT โดยมีผลกระทบด้านข้างที่ยอมรับได้ (REST)
ฉันต้องการสร้างประวัติการเลิกทำเมื่อใดก็ตามที่ผู้ใช้อัปเดตฟอร์ม เนื่องจากเป็นการอัปเดตฉันต้องการใช้คำขอ PUT แต่ผมอ่านที่ความต้องการนำไปไม่มีผลข้างเคียง เป็นที่ยอมรับหรือไม่ที่จะใช้ PUT ที่นี่ มีทางเลือกที่ดีกว่านี้ไหม? PUT /person/F02E395A235 { time: 1234567, fields: { name: 'John', age: '41' } } ในเซิร์ฟเวอร์ doPut('person/:personId', // create a new person snapshot ) แก้ไข: ผู้ใช้จะสามารถเห็นประวัติได้การเรียกหลายครั้งจะทำให้หลายเวอร์ชัน วิธีแก้ไขคือการตรวจสอบว่าเป็นรุ่นที่ไม่ซ้ำกันก่อนที่จะสร้างมัน
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.