สถาปัตยกรรม API ภายในและภายนอก

บริษัท ที่ฉันทำงานเพื่อรักษาผลิตภัณฑ์ SaaS ที่ประสบความสำเร็จซึ่งเติบโตขึ้นอย่าง "เป็น" ในช่วงหลายปีที่ผ่านมา เราวางแผนที่จะขยายสายผลิตภัณฑ์ใหม่ที่จะใช้ข้อมูลร่วมกันกับผลิตภัณฑ์ที่มีอยู่ เพื่อสนับสนุนสิ่งนี้เราต้องการรวมตรรกะทางธุรกิจไว้ในที่เดียวนั่นคือเลเยอร์บริการเว็บ เลเยอร์ WS จะถูกใช้โดย:

• เว็บแอพพลิเคชั่น
• เครื่องมือในการนำเข้าข้อมูล
• เครื่องมือที่จะรวมเข้ากับซอฟต์แวร์ไคลเอ็นต์อื่น ๆ (ไม่ใช่ API ต่อ se)

เราต้องการสร้าง API ที่ลูกค้าของเราสามารถใช้เพื่อสร้างการรวมระบบของพวกเขาเอง เรากำลังดิ้นรนกับคำถามต่อไปนี้:

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

คนอื่น ๆ ทำอะไรในสถานการณ์คล้ายกัน

มันเป็นการดีเสมอที่จะกินอาหารสุนัขของคุณเอง API หนึ่งรายการควรมีความง่ายในการบำรุงรักษามากกว่าสองรายการแม้ว่าคุณจะคำนึงถึงค่าใช้จ่ายในการตรวจสอบสิทธิ์และการอนุญาต

แม้ว่าฉันจะเห็นด้วยกับ Aneurysm9 บางครั้งคุณไม่ต้องการเปิดเผยความสามารถทั้งหมดของระบบของคุณ ในกรณีนี้มีสอง API จะดีกว่า ... แต่ ถ้าคุณเลือกวิธีนี้ ... โปรดตรวจสอบให้แน่ใจว่าทุกฟังก์ชั่นทั่วไปใช้ API เดียวกัน, IE ที่หนึ่งเป็นรุ่นเพิ่มเติมของตรงข้ามกับสองที่แตกต่างกัน ชุดของรหัส

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

ฉันเคยพบสิ่งนี้มาก่อน (หลายครั้ง) และสิ่งที่ฉันชอบทำคือ:

นำ BL ออกจากเว็บไซต์ ทำให้เว็บไซต์เป็นผู้บริโภคของ API ปฏิบัติต่อเว็บไซต์เหมือนกับลูกค้าอื่น ๆ ของ API ของคุณ API ของคุณคือบริการ

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

ไม่เชื่อ

ก้าวไปอีกขั้น ...

แอพโทรศัพท์กำลังทำงานบนแพลตฟอร์มที่มีการดำเนินการตาม bytecode แอพอาศัยอยู่ในโทรศัพท์และใช้บริการ API ผ่าน HTTP / JSON

เว็บไซต์เป็นแอปที่ทำงานบนแพลตฟอร์มที่มีการเรียกใช้งาน HTML + Javascript แอปนั้นอาศัยอยู่ในเบราว์เซอร์และใช้บริการ API ผ่าน HTTP / JSON

เหมือนกัน!

ขยายไปยังแท็บเล็ตทีวีแพลตฟอร์มโทรศัพท์อื่น ๆ ปลั๊กอินแอปของบุคคลที่สามผสม ...

ประสบการณ์ผู้ใช้ที่แตกต่างกันมากมายเชื่อมต่อกับ API ทั่วไป

แอปของคุณคือ API เว็บไซต์เป็นเพียงลูกค้าคนเดียว (จากหลาย ๆ )

ใช้หนึ่ง API

หากคุณกำลังใช้ Service API เป็นเลเยอร์ REST เพียงเพิ่มการรับรองความถูกต้องไปยังเส้นทางที่ได้รับการป้องกัน

คุณอาจต้องการใช้กรอบการพัฒนาที่ไม่ได้อบใน 'วิเศษ' มากเกินไป สิ่งที่คุณสามารถกำหนดเส้นทางได้โดยตรงโดยไม่มีวิศวกรรมย้อนกลับมากมาย

คิดอย่าง Node.js / Express, python / pylons, python / google app engine เป็นต้น

ฉันเพิ่งนำสิ่งนี้ไปใช้กับ Google App Engine เพื่อใช้ REST / Datastore API และฉันคิดว่าคงไม่ง่ายกว่านี้แล้ว ตัวควบคุมถูกนำไปใช้เป็นคลาสและคำร้องขอ HTTP ที่ตามมา (เช่น GET / POST / PUT / DELETE) ถูกใช้เป็นวิธีการของคลาสเหล่านั้น ฉันจัดการเพื่อใช้การรับรองความถูกต้องขั้นพื้นฐานเป็นมัณฑนากร ซึ่งทำให้การเพิ่มข้อกำหนดการตรวจสอบสิทธิ์ให้กับคำร้องขอนั้นง่ายเหมือนการแนบ @basicAuth decorator

ด้วยวิธีนี้ฉันสามารถสร้างคำขอ GET ที่เข้ามาแบบสาธารณะเพิ่มข้อกำหนดการรับรองความถูกต้องให้กับคำขอ POST / PUT / DELETE บนคอนโทรลเลอร์เดียวกันสำหรับรุ่นนั้น

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

ความประทับใจแรกของฉันคือมันควรเป็น API เดียวกันและความปลอดภัยของคุณควรอยู่ในเลเยอร์ที่แตกต่างกันโดยสิ้นเชิง บางทีการจัดการโดยหน้าเว็บ?