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

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

9 rest  api  api-design 

สมมติว่าคุณมีโครงสร้างข้อมูลบางประเภทซึ่งยังคงอยู่ในฐานข้อมูลบางประเภท เพื่อความง่ายเราจะเรียกโครงสร้างข้อมูล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การอัปเดต? วิธีแก้ปัญหาที่ฉันสามารถทำได้: คุณสามารถกำหนดให้บุคคลที่สมบูรณ์ต้องผ่านเช่นลูกค้าจะทำสิ่งนี้เพื่ออัปเดตวันเกิด: …

9 design  api  web-services  api-design  crud 

โดยทั่วไปผู้ฟังเหตุการณ์ไม่ควรอยู่เหนือกว่าวัตถุที่ลงทะเบียนไว้ หมายความว่าผู้ฟังเหตุการณ์ควรจัดขึ้นโดยการอ้างอิงที่อ่อนแอตามค่าเริ่มต้น (เก็บไว้ในคอลเลกชันที่อ่อนแอโดยผู้ฟังวัตถุที่ลงทะเบียนไว้) มีกรณีที่ถูกต้องหรือไม่เมื่อผู้ฟังควรมีอายุยืนกว่าผู้สร้าง หรืออาจเป็นเช่นนั้นเป็นความผิดพลาดและไม่ควรอนุญาต

9 api-design  event 

สมมติว่าคุณมีโครงการขนาดใหญ่ที่สนับสนุนโดย API พื้นฐาน โครงการนี้ยังจัดส่ง API สาธารณะที่ผู้ใช้สามารถใช้ (สิ้นสุด) บางครั้งคุณต้องทำการเปลี่ยนแปลงฐาน API ที่สนับสนุนโครงการของคุณ ตัวอย่างเช่นคุณต้องเพิ่มคุณสมบัติที่ต้องมีการเปลี่ยนแปลง API วิธีการใหม่หรือต้องการแก้ไขวัตถุใดวัตถุหนึ่งหรือรูปแบบของวัตถุเหล่านั้นอย่างใดอย่างหนึ่งผ่านไปหรือกลับจาก API สมมติว่าคุณกำลังใช้วัตถุเหล่านี้ใน API สาธารณะของคุณวัตถุสาธารณะก็จะเปลี่ยนทุกครั้งที่คุณทำเช่นนี้ซึ่งไม่พึงประสงค์เนื่องจากลูกค้าของคุณอาจพึ่งพาวัตถุ API ที่เหลือเหมือนกันสำหรับรหัสการแยกวิเคราะห์เพื่อทำงาน (ไคลเอนต์ C ++ WSDL สำหรับไอ ... ) ดังนั้นทางออกที่เป็นไปได้หนึ่งอย่างก็คือการเวอร์ชั่น API แต่เมื่อเราพูดว่า "version" API ดูเหมือนว่านี่จะต้องหมายถึงวัตถุรุ่น API เช่นเดียวกับการให้การเรียกใช้วิธีที่ซ้ำกันสำหรับลายเซ็นวิธีการที่เปลี่ยนไปแต่ละอัน ดังนั้นฉันจะมีวัตถุ clr แบบธรรมดาสำหรับ api ของฉันแต่ละรุ่นซึ่งดูเหมือนจะไม่พึงประสงค์อีกครั้ง และแม้ว่าฉันจะทำสิ่งนี้ฉันก็จะไม่สร้างแต่ละวัตถุตั้งแต่เริ่มต้นเพราะจะจบลงด้วยการทำซ้ำรหัสจำนวนมหาศาล แต่ API มีแนวโน้มที่จะขยายออบเจ็กต์ส่วนตัวที่เราใช้สำหรับ API พื้นฐานของเรา แต่จากนั้นเราพบปัญหาเดียวกันเนื่องจากคุณสมบัติที่เพิ่มเข้ามาจะมีให้บริการใน API สาธารณะเมื่อไม่ควรจะเป็นเช่นนั้น ดังนั้นสติบางอย่างที่มักใช้กับสถานการณ์นี้คืออะไร? ฉันรู้ว่าบริการสาธารณะจำนวนมากเช่น …

9 versioning  api-design