ข้ามไปที่เนื้อหาหลัก

DNS

 

วิกิพีเดีย

API

สำหรับการใช้งานอื่นๆ โปรดดูที่API (disambiguation )
"Api.php" เปลี่ยนเส้นทางที่นี่ สำหรับ Wikipedia API โปรดดูที่ Special: ApiHelp

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

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

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

คำว่า API มักใช้เพื่ออ้างถึงAPI บนเว็บ [ 2 ]ซึ่งอนุญาตให้มีการสื่อสารระหว่างคอมพิวเตอร์ที่เชื่อมต่อกันผ่านอินเทอร์เน็ตนอกจากนี้ยังมี API สำหรับภาษาโปรแกรมไลบรารีซอฟต์แวร์ระบบปฏิบัติการคอมพิวเตอร์และฮาร์ดแวร์คอมพิวเตอร์ API มีต้นกำเนิดในช่วงทศวรรษ 1940 แม้ว่าคำนี้จะปรากฏขึ้นในช่วงทศวรรษ 1960 และ 1970 ก็ตาม

วัตถุประสงค์

API เปิดระบบซอฟต์แวร์ให้มีการโต้ตอบจากภายนอก ช่วยให้ระบบซอฟต์แวร์สองระบบสามารถสื่อสารกันข้ามขอบเขต — อินเทอร์เฟซ — โดยใช้สัญญาณที่ตกลงร่วมกัน[ 3 ]กล่าวอีกนัยหนึ่ง API เชื่อมต่อเอนทิตีซอฟต์แวร์เข้าด้วยกัน ต่างจากอินเทอร์เฟซผู้ใช้ API โดยทั่วไปจะไม่ปรากฏให้ผู้ใช้เห็น เป็นส่วน "เบื้องหลัง" ของระบบซอฟต์แวร์ที่ใช้สำหรับการสื่อสารระหว่างเครื่อง[ 4 ]

API ที่ออกแบบมาอย่างดีจะเปิดเผยเฉพาะวัตถุหรือการกระทำที่จำเป็นสำหรับซอฟต์แวร์หรือนักพัฒนาซอฟต์แวร์เท่านั้น โดยจะซ่อนรายละเอียดที่ไม่มีประโยชน์ การสร้าง นามธรรม นี้ ทำให้การเขียนโปรแกรมง่ายขึ้น[ 5 ]

โดยเปรียบเทียบแล้ว API เปรียบเสมือนตัวต่อที่เชื่อมต่อซอฟต์แวร์เข้าด้วยกัน

การสร้างซอฟต์แวร์โดยใช้ API ได้รับการเปรียบเทียบกับการใช้ของเล่นตัวต่อ เช่น อิฐ เลโก้บริการซอฟต์แวร์หรือไลบรารีซอฟต์แวร์เปรียบเสมือนอิฐ พวกมันสามารถเชื่อมต่อกันได้ผ่าน API เพื่อสร้างผลิตภัณฑ์ซอฟต์แวร์ใหม่[ 6 ]กระบวนการเชื่อมต่อนี้เรียกว่าการบูรณาการ[ 3 ]

ตัวอย่างเช่น ลองพิจารณาเซ็นเซอร์สภาพอากาศที่ให้บริการ API เมื่อมีการส่งข้อความบางอย่างไปยังเซ็นเซอร์ เซ็นเซอร์จะตรวจจับสภาพอากาศปัจจุบันและตอบกลับด้วยรายงานสภาพอากาศ ข้อความที่เปิดใช้งานเซ็นเซอร์คือการเรียกใช้ API และรายงานสภาพอากาศคือการตอบสนองของ API [ 7 ]แอปพยากรณ์อากาศอาจผสานรวมกับ API ของเซ็นเซอร์สภาพอากาศหลายตัว เพื่อรวบรวมข้อมูลสภาพอากาศจากทั่วพื้นที่ทางภูมิศาสตร์

API มักถูกเปรียบเทียบกับสัญญาโดยเป็นตัวแทนของข้อตกลงระหว่างคู่สัญญา ได้แก่ ผู้ให้บริการที่เสนอ API และนักพัฒนาซอฟต์แวร์ที่พึ่งพา API นั้น หาก API มีความเสถียร หรือมีการเปลี่ยนแปลงเฉพาะในรูปแบบที่คาดการณ์ได้ ความเชื่อมั่นของนักพัฒนาที่มีต่อ API ก็จะเพิ่มขึ้น ซึ่งอาจทำให้การใช้งาน API เพิ่มขึ้น[ 8 ]

ประวัติความเป็นมาของคำนี้

แผนภาพจากปี 1978 เสนอให้ขยายแนวคิดของ API ให้กลายเป็นอินเทอร์เฟซการเขียนโปรแกรมทั่วไป นอกเหนือจากโปรแกรมแอปพลิเคชันเพียงอย่างเดียว[ 9 ]

เดิมที คำว่าAPIใช้เพื่ออธิบายอินเทอร์เฟซสำหรับโปรแกรมที่ผู้ใช้ปลายทางใช้งานเท่านั้น ซึ่งเรียกว่าโปรแกรมแอปพลิเคชัน ต้นกำเนิดนี้ยังคงสะท้อนให้เห็นในชื่อ "อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน" ปัจจุบันคำนี้มีความหมายกว้างขึ้น รวมถึงซอฟต์แวร์ยูทิลิตี้และแม้แต่อินเทอร์เฟซฮาร์ดแวร์ด้วย[ 10 ]

แนวคิดของ API นั้นเก่าแก่กว่าคำศัพท์นี้มาก นักวิทยาศาสตร์คอมพิวเตอร์ชาวอังกฤษMaurice WilkesและDavid Wheelerได้ทำงานเกี่ยวกับไลบรารีซอฟต์แวร์ แบบโมดูลาร์ ในช่วงทศวรรษ 1940 สำหรับEDSACซึ่งเป็นคอมพิวเตอร์รุ่นแรกๆ ซับรูทีนในไลบรารีนี้ถูกจัดเก็บไว้บนเทปกระดาษเจาะรูที่จัดเรียงไว้ในตู้เก็บเอกสาร ตู้นี้ยังประกอบด้วยสิ่งที่ Wilkes และ Wheeler เรียกว่า "แคตตาล็อกไลบรารี" ของบันทึกเกี่ยวกับซับรูทีนแต่ละตัวและวิธีการรวมเข้ากับโปรแกรม ปัจจุบัน แคตตาล็อกดังกล่าวจะถูกเรียกว่า API (หรือข้อกำหนด API หรือเอกสารประกอบ API) เพราะมันแนะนำโปรแกรมเมอร์เกี่ยวกับวิธีการใช้ (หรือ "เรียก") ซับรูทีนแต่ละตัวที่โปรแกรมเมอร์ต้องการ[ 10 ]

หนังสือ The Preparation of Programs for an Electronic Digital Computerของ Wilkes และ Wheeler มีข้อกำหนด API ที่ตีพิมพ์ครั้งแรกJoshua Blochถือว่า Wilkes และ Wheeler "คิดค้น" API โดยปริยาย เนื่องจากเป็นแนวคิดที่ถูกค้นพบมากกว่าถูกคิดค้น[ 10 ]

แม้ว่าผู้ที่คิดค้นคำว่า API จะทำการพัฒนาซอฟต์แวร์บนUnivac 1108แต่เป้าหมายของ API ของพวกเขาก็คือการทำให้โปรแกรมที่ไม่ขึ้นกับฮาร์ดแวร์ เป็นไปได้ [ 11 ]

คำว่า "อินเทอร์เฟซโปรแกรมแอปพลิเคชัน" (โดยไม่มี คำต่อท้าย -ing ) ถูกบันทึกไว้ครั้งแรกในเอกสารชื่อโครงสร้างข้อมูลและเทคนิคสำหรับกราฟิกคอมพิวเตอร์ ระยะไกล ที่นำเสนอใน การประชุม AFIPSในปี 1968 [ 12 ] [ 10 ]ผู้เขียนเอกสารนี้ใช้คำนี้เพื่ออธิบายปฏิสัมพันธ์ของแอปพลิเคชัน —ในกรณีนี้คือโปรแกรมกราฟิก—กับส่วนที่เหลือของระบบคอมพิวเตอร์ อินเทอร์เฟซแอปพลิเคชันที่สอดคล้องกัน (ประกอบด้วย การเรียกใช้ซับรูทีน Fortran ) มีจุดประสงค์เพื่อปลดปล่อยโปรแกรมเมอร์จากการจัดการกับลักษณะเฉพาะของอุปกรณ์แสดงผลกราฟิก และเพื่อให้เกิดความเป็นอิสระของฮาร์ดแวร์หากมีการเปลี่ยนคอมพิวเตอร์หรือจอแสดงผล[ 11 ]

คำนี้ได้รับการแนะนำเข้าสู่สาขาฐานข้อมูลโดยCJ Date [ 13 ]ในบทความปี 1974 ที่ชื่อว่าThe Relational and Network Approaches : Comparison of the Application Programming Interface [ 14 ] API กลายเป็นส่วนหนึ่งของเฟรมเวิร์ก ANSI/SPARCสำหรับระบบจัดการฐานข้อมูลเฟรมเวิร์กนี้ถือว่า Application Programming Interface แยกต่างหากจากอินเทอร์เฟซอื่นๆ เช่น อินเทอร์เฟซการสืบค้น ผู้เชี่ยวชาญด้านฐานข้อมูลในช่วงปี 1970 สังเกตเห็นว่าอินเทอร์เฟซต่างๆ เหล่านี้สามารถรวมกันได้ อินเทอร์เฟซแอปพลิเคชันที่สมบูรณ์เพียงพอสามารถรองรับอินเทอร์เฟซอื่นๆ ได้เช่นกัน[ 9 ]

การสังเกตนี้ทำให้เกิด API ที่รองรับการเขียนโปรแกรมทุกประเภท ไม่ใช่แค่การเขียนโปรแกรมแอปพลิเคชันเท่านั้น ในปี 1990 นักเทคโนโลยี Carl Malamudได้นิยาม API อย่างง่ายๆ ว่า "ชุดบริการที่มีให้แก่โปรแกรมเมอร์เพื่อดำเนินการบางอย่าง" [ 15 ]

ภาพหน้าจอเอกสาร ประกอบการใช้งาน Web APIที่เขียนโดยNASA

แนวคิดของ API ได้รับการขยายอีกครั้งด้วยการเกิดขึ้นของการเรียกใช้ฟังก์ชันระยะไกลและเว็บ APIเมื่อเครือข่ายคอมพิวเตอร์แพร่หลายมากขึ้นในช่วงทศวรรษ 1970 และ 1980 โปรแกรมเมอร์ต้องการเรียกใช้ไลบรารีที่ไม่ได้อยู่แค่ในคอมพิวเตอร์ของตนเองเท่านั้น แต่ยังรวมถึงคอมพิวเตอร์ที่ตั้งอยู่ในที่อื่นด้วย การเรียกใช้ฟังก์ชันระยะไกลเหล่านี้ได้รับการสนับสนุนเป็นอย่างดีโดยเฉพาะอย่างยิ่งใน ภาษา Javaในช่วงทศวรรษ 1990 ด้วยการแพร่กระจายของอินเทอร์เน็ตมาตรฐานต่างๆ เช่นCORBA , COMและDCOMได้แข่งขันกันเพื่อเป็นวิธีที่ใช้กันทั่วไปในการเปิดเผยบริการ API [ 16 ]

วิทยานิพนธ์ของRoy Fielding เรื่อง Architectural Styles and the Design of Network-based Software Architecturesที่UC Irvineในปี 2000 ได้สรุปRepresentational state transfer (REST) ​​และอธิบายแนวคิดของ "Application Programming Interface บนเครือข่าย" ซึ่ง Fielding เปรียบเทียบกับ API แบบดั้งเดิมที่ "อิงตามไลบรารี" [ 17 ] API เว็บ XMLและJSONได้รับการนำไปใช้ในเชิงพาณิชย์อย่างแพร่หลายตั้งแต่ปี 2000 และต่อเนื่องมาจนถึงปี 2021 ปัจจุบัน API เว็บเป็นความหมายที่พบได้บ่อยที่สุดของคำว่า API [ 2 ]

เว็บเชิงความหมาย (Semantic Web)ที่เสนอโดยTim Berners-Leeในปี 2001 ประกอบด้วย "API เชิงความหมาย" (semantic API) ซึ่งปรับเปลี่ยน API ให้เป็น อินเทอร์เฟซข้อมูล แบบเปิดและกระจาย แทนที่จะเป็นอินเทอร์เฟซพฤติกรรมซอฟต์แวร์[ 18 ] อินเทอร์เฟซและเอเจนต์ ที่เป็นกรรมสิทธิ์แพร่หลายมากกว่าแบบเปิด แต่แนวคิดของ API ในฐานะอินเทอร์เฟซข้อมูลก็ได้รับการยอมรับ เนื่องจากเว็บ API ถูกใช้กันอย่างแพร่หลายในการแลกเปลี่ยนข้อมูลทุกประเภททางออนไลน์ API จึงกลายเป็นคำกว้างๆ ที่อธิบายการสื่อสารส่วนใหญ่บนอินเทอร์เน็ต[ 16 ]เมื่อใช้ในลักษณะนี้ คำว่า API จึงมีความหมายทับซ้อนกับคำว่าโปรโตคอลการสื่อสาร

ประเภท

ห้องสมุดและเฟรมเวิร์ก

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

API เดียวสามารถมีการใช้งานหลายแบบ (หรือไม่มีเลย เนื่องจากเป็นนามธรรม) ในรูปแบบของไลบรารีต่างๆ ที่ใช้ส่วนต่อประสานการเขียนโปรแกรมเดียวกัน

การแยก API ออกจากการใช้งานจะช่วยให้โปรแกรมที่เขียนด้วยภาษาหนึ่งสามารถใช้ไลบรารีที่เขียนด้วยภาษาอื่นได้ ตัวอย่างเช่น เนื่องจากScalaและJavaคอมไพล์เป็นไบต์โค้ด ที่เข้ากันได้ นักพัฒนา Scala จึงสามารถใช้ประโยชน์จาก API ของ Java ได้[ 19 ]

การใช้งาน API อาจแตกต่างกันไปขึ้นอยู่กับประเภทของภาษาโปรแกรมที่เกี่ยวข้อง API สำหรับภาษาเชิงขั้นตอนเช่นLuaอาจประกอบด้วยรูทีนพื้นฐานเพื่อเรียกใช้โค้ด จัดการข้อมูล หรือจัดการข้อผิดพลาด ในขณะที่ API สำหรับภาษาเชิงวัตถุเช่น Java จะให้ข้อกำหนดของคลาสและเมธอด ของ คลาส[ 20 ] [ 21 ] กฎของไฮรัมระบุว่า "เมื่อมีผู้ใช้ API จำนวนมากพอ ไม่ว่าคุณจะสัญญาอะไรไว้ในสัญญา พฤติกรรมที่สังเกตได้ทั้งหมดของระบบของคุณจะขึ้นอยู่กับใครบางคน" [ 22 ]ในขณะเดียวกัน การศึกษาหลายชิ้นแสดงให้เห็นว่าแอปพลิเคชันส่วนใหญ่ที่ใช้ API มักจะใช้เพียงส่วนเล็ก ๆ ของ API เท่านั้น [ 23 ]

การเชื่อมโยงภาษาก็คือ API เช่นกัน การเชื่อมโยงภาษาช่วยให้สามารถใช้ไลบรารีหรือบริการที่เขียนด้วยภาษาหนึ่งเมื่อพัฒนาด้วยภาษาอื่นได้ โดยการแมปคุณสมบัติและความสามารถของภาษาหนึ่งไปยังอินเทอร์เฟซที่เขียนด้วยภาษาอื่น[ 24 ]เครื่องมือต่างๆ เช่นSWIGและ F2PY ซึ่ง เป็นตัวสร้างอินเทอร์เฟซ Fortranเป็นPythonช่วยอำนวยความสะดวกในการสร้างอินเทอร์เฟซดังกล่าว[ 25 ]

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

ยิ่งไปกว่านั้น การควบคุมการไหลของโปรแกรมโดยรวมอาจอยู่นอกเหนือการควบคุมของผู้เรียกและอยู่ในมือของเฟรมเวิร์กโดยการกลับด้านการควบคุมหรือกลไกที่คล้ายกัน[ 26 ] [ 27 ]

ระบบปฏิบัติการ

API สามารถระบุอินเทอร์เฟซระหว่างแอปพลิเคชันและระบบปฏิบัติการได้[ 28 ] ตัวอย่างเช่น POSIXระบุชุด API ทั่วไปที่มีจุดมุ่งหมายเพื่อให้แอปพลิเคชันที่เขียนขึ้นสำหรับระบบปฏิบัติการที่สอดคล้องกับ POSIX สามารถคอมไพล์สำหรับระบบปฏิบัติการที่สอดคล้องกับ POSIX อื่นได้

LinuxและBerkeley Software Distributionเป็นตัวอย่างของระบบปฏิบัติการที่ใช้ API ของ POSIX [ 29 ]

ไมโครซอฟต์ได้แสดงความมุ่งมั่นอย่างแรงกล้าต่อ API ที่เข้ากันได้กับเวอร์ชันก่อนหน้า โดยเฉพาะอย่างยิ่งภายใน ไลบรารี Windows API (Win32) ดังนั้นแอปพลิเคชันรุ่นเก่าจึงสามารถทำงานบน Windows เวอร์ชันใหม่กว่าได้โดยใช้การตั้งค่าเฉพาะไฟล์ปฏิบัติการที่เรียกว่า "โหมดความเข้ากันได้" [ 30 ]ยังไม่ชัดเจนว่าการที่นักพัฒนาของไมโครซอฟต์เข้าถึง API ภายในของระบบปฏิบัติการของบริษัทนั้นเป็นข้อได้เปรียบมากน้อยเพียงใด Richard A. Shaffer จากTechnologic Computer Letterในปี 1987 เปรียบเทียบสถานการณ์นี้กับเกมเบสบอลที่ "ไมโครซอฟต์เป็นเจ้าของไม้เบสบอลและสนามทั้งหมด" [ 31 ]และผู้จำหน่ายรายใหญ่เช่นLotus DevelopmentและAshton-Tateได้รับข้อมูลเกี่ยวกับMS-DOS 5.0ที่นักพัฒนาซอฟต์แวร์รายเล็กไม่ได้รับ[ 32 ] อย่างไรก็ตามEd Esber จาก Ashton-Tate กล่าวในการสัมภาษณ์ในปี 1987 ว่า Bill Gatesบอกเขาว่านักพัฒนาของเขาบางครั้งต้องเขียนซอฟต์แวร์ใหม่โดยอิงจาก API รุ่นแรกๆ Gates กล่าวในการสัมภาษณ์ว่า แอปพลิเคชัน Apple Macintosh ของ Microsoft ประสบความสำเร็จมากกว่าแอปพลิเคชันสำหรับ MS-DOS เนื่องจากบริษัทของเขาไม่ต้องทุ่มเททรัพยากรให้กับMac OSด้วย[ 33 ]

API แตกต่างจากอินเทอร์เฟซไบนารีแอปพลิเคชัน (ABI) ตรงที่ API ใช้ซอร์สโค้ดเป็นพื้นฐาน ในขณะที่ ABI ใช้ไบนารี เป็น พื้นฐาน ตัวอย่างเช่นPOSIXมี API ในขณะที่Linux Standard Baseมี ABI [ 34 ] [ 35 ]

API ระยะไกล

API ระยะไกลช่วยให้นักพัฒนาสามารถจัดการทรัพยากรระยะไกลผ่านโปรโตคอลซึ่งเป็นมาตรฐานเฉพาะสำหรับการสื่อสารที่ช่วยให้เทคโนโลยีต่างๆ สามารถทำงานร่วมกันได้โดยไม่คำนึงถึงภาษาหรือแพลตฟอร์ม ตัวอย่างเช่น Java Database Connectivity API ช่วยให้นักพัฒนาสามารถสอบถามฐานข้อมูล ประเภทต่างๆ ได้มากมาย ด้วยชุดฟังก์ชันเดียวกัน ในขณะที่Java remote method invocation API ใช้ Java Remote Method Protocol เพื่ออนุญาตให้เรียกใช้ฟังก์ชันที่ทำงานจากระยะไกล แต่ปรากฏว่าทำงานในพื้นที่สำหรับนักพัฒนา[ 36 ] [ 37 ]

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

การแก้ไขวัตถุพร็อกซีจะส่งผลให้เกิดการแก้ไขวัตถุระยะไกลที่สอดคล้องกันด้วย[ 38 ]

เว็บ API

บทความหลัก: เว็บ API

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

เมื่อใช้ในบริบทของการพัฒนาเว็บ API มักถูกนิยามว่าเป็นชุดของข้อกำหนด เช่น ข้อความคำขอ Hypertext Transfer Protocol (HTTP) พร้อมกับคำจำกัดความของโครงสร้างของข้อความตอบกลับ ซึ่งโดยปกติจะอยู่ในรูปแบบ Extensible Markup Language ( XML ) หรือ JavaScript Object Notation ( JSON ) ตัวอย่างเช่น API ของบริษัทขนส่งที่สามารถเพิ่มลงในเว็บไซต์อีคอมเมิร์ซเพื่ออำนวยความสะดวกในการสั่งซื้อบริการขนส่งและรวมอัตราค่าจัดส่งปัจจุบันโดยอัตโนมัติ โดยที่นักพัฒนาเว็บไซต์ไม่ต้องป้อนตารางอัตราของบริษัทขนส่งลงในฐานข้อมูลเว็บ ในขณะที่ "เว็บ API" ในอดีตแทบจะมีความหมายเหมือนกับเว็บเซอร์วิสแต่แนวโน้มล่าสุด( ที่เรียกว่าWeb 2.0 ) ได้เปลี่ยนจากเว็บเซอร์วิส แบบ Simple Object Access Protocol ( SOAP ) และ สถาปัตยกรรมแบบบริการเป็นศูนย์กลาง (SOA) ไปสู่ เว็บรีซอร์ส แบบ Representational State Transfer (REST) ​​และสถาปัตยกรรมแบบทรัพยากรเป็นศูนย์กลาง (ROA) ที่ตรงไปตรงมามากขึ้น[ 40 ]ส่วนหนึ่งของแนวโน้มนี้เกี่ยวข้องกับการเคลื่อนไหว ของ Semantic Web ไปสู่ ​​Resource Description Framework (RDF) ซึ่งเป็นแนวคิดเพื่อส่งเสริมเทคโนโลยี วิศวกรรมออนโทโลยีบนเว็บWeb API อนุญาตให้รวม API หลายตัวเข้าด้วยกันเป็นแอปพลิเคชันใหม่ที่เรียกว่าmashup [ 41 ] ในพื้นที่สื่อสังคมออนไลน์ Web API ช่วยให้ชุมชนบนเว็บสามารถอำนวยความสะดวกในการแบ่งปันเนื้อหาและข้อมูลระหว่างชุมชนและแอปพลิเคชันต่างๆ ด้วยวิธีนี้ เนื้อหาที่สร้างขึ้นในที่หนึ่งสามารถโพสต์และอัปเดตไปยังหลายตำแหน่งบนเว็บได้อย่างไดนามิก[ 42 ]ตัวอย่างเช่น REST API ของ Twitter อนุญาตให้นักพัฒนาเข้าถึงข้อมูลหลักของ Twitter และ Search API มีวิธีการสำหรับนักพัฒนาในการโต้ตอบกับข้อมูลการค้นหาและแนวโน้มของ Twitter [ 43 ]

ออกแบบ

การออกแบบ API มีผลกระทบอย่างมากต่อการใช้งาน[ 5 ]หลักการของการซ่อนข้อมูลอธิบายบทบาทของอินเทอร์เฟซการเขียนโปรแกรมว่าช่วยให้การเขียนโปรแกรมแบบโมดูลาร์ เป็นไปได้ โดยการซ่อนรายละเอียดการใช้งานของโมดูล เพื่อให้ผู้ใช้โมดูลไม่จำเป็นต้องเข้าใจความซับซ้อนภายในโมดูล[ 44 ]ดังนั้น การออกแบบ API จึงพยายามจัดหาเฉพาะเครื่องมือที่ผู้ใช้คาดหวัง[ 5 ]การออกแบบอินเทอร์เฟซการเขียนโปรแกรมเป็นส่วนสำคัญของสถาปัตยกรรมซอฟต์แวร์ซึ่งเป็นการจัดระเบียบซอฟต์แวร์ที่ซับซ้อน[ 45 ]

นโยบายการเผยแพร่

API เป็นหนึ่งในวิธีการบูรณาการที่พบได้บ่อยในบริษัทเทคโนโลยี บริษัทที่ให้บริการและใช้ API ถือว่าเป็นสมาชิกของระบบนิเวศทางธุรกิจ[ 46 ]

นโยบายหลักสำหรับการเผยแพร่ API คือ: [ 47 ]

  • ส่วนตัว : API นี้มีไว้สำหรับใช้งานภายในบริษัทเท่านั้น
  • พันธมิตร : เฉพาะพันธมิตรทางธุรกิจที่ระบุไว้เท่านั้นที่สามารถใช้ API ได้ ตัวอย่างเช่น บริษัท ให้เช่ารถอย่างUberและLyftอนุญาตให้นักพัฒนาบุคคลที่สามที่ได้รับอนุมัติสั่งรถได้โดยตรงจากภายในแอปของตน ซึ่งช่วยให้บริษัทเหล่านี้สามารถควบคุมคุณภาพได้โดยการคัดเลือกแอปที่สามารถเข้าถึง API และยังช่วยให้พวกเขามีรายได้เพิ่มขึ้นอีกด้วย[ 48 ]
  • สาธารณะ : API เปิดให้สาธารณะใช้งานได้ ตัวอย่างเช่นMicrosoftเปิดให้ ใช้งาน Windows APIและApple เผยแพร่ Cocoa API เพื่อให้สามารถเขียนซอฟต์แวร์สำหรับแพลตฟอร์ม ของตน ได้ ไม่ใช่ว่า API สาธารณะทั้งหมดจะสามารถเข้าถึงได้โดยทุกคน ตัวอย่างเช่น ผู้ให้บริการอินเทอร์เน็ตอย่าง Cloudflare หรือ Voxility ใช้RESTful API เพื่ออนุญาตให้ลูกค้าและผู้ค้าปลีกเข้าถึงข้อมูลโครงสร้างพื้นฐาน สถิติ DDoS ประสิทธิภาพเครือข่าย หรือการควบคุมแดชบอร์ด[ 49 ]การเข้าถึง API ดังกล่าวจะได้รับอนุญาตโดยใช้ “โทเค็น API” หรือการตรวจสอบสถานะของลูกค้า[ 50 ]

ผลกระทบของ API สาธารณะ

ปัจจัยสำคัญเมื่อ API กลายเป็นสาธารณะคือ "ความเสถียรของอินเทอร์เฟซ" การเปลี่ยนแปลง API เช่น การเพิ่มพารามิเตอร์ใหม่ในการเรียกฟังก์ชัน อาจทำให้ความเข้ากันได้กับไคลเอ็นต์ที่ขึ้นอยู่กับ API นั้นเสียหายได้[ 51 ]

เมื่อส่วนต่างๆ ของ API ที่นำเสนอต่อสาธารณะอาจมีการเปลี่ยนแปลงและไม่เสถียร ส่วนต่างๆ ของ API นั้นๆ ควรได้รับการบันทึกอย่างชัดเจนว่าเป็น "ไม่เสถียร" ตัวอย่างเช่น ใน ไลบรารี Google Guavaส่วนที่ถือว่าไม่เสถียรและอาจมีการเปลี่ยนแปลงในเร็วๆ นี้ จะถูกทำเครื่องหมายด้วย คำอธิบาย ประกอบJava [ 52 ]@Beta

บางครั้ง API สาธารณะอาจประกาศส่วนต่างๆ ของตัวเองว่าล้าสมัยหรือถูกยกเลิก ซึ่งโดยปกติแล้วหมายความว่าส่วนนั้นของ API ควรได้รับการพิจารณาให้ลบออก หรือแก้ไขในลักษณะที่ไม่เข้ากันกับเวอร์ชันก่อนหน้า ดังนั้น การเปลี่ยนแปลงเหล่านี้จะช่วยให้นักพัฒนาสามารถเปลี่ยนไปใช้ส่วนอื่นๆ ของ API ที่จะถูกลบออกหรือไม่ได้รับการสนับสนุนในอนาคตได้[ 53 ]

รหัสไคลเอ็นต์อาจมีการใช้งานที่สร้างสรรค์หรือฉวยโอกาสซึ่งไม่ได้ตั้งใจโดยนักออกแบบ API กล่าวอีกนัยหนึ่ง สำหรับไลบรารีที่มีฐานผู้ใช้จำนวนมาก เมื่อองค์ประกอบกลายเป็นส่วนหนึ่งของ API สาธารณะ อาจมีการใช้งานในหลากหลายวิธี[ 54 ]เมื่อวันที่ 19 กุมภาพันธ์ 2020 Akamaiได้เผยแพร่รายงาน “สถานการณ์อินเทอร์เน็ต” ประจำปี ซึ่งแสดงให้เห็นถึงแนวโน้มที่เพิ่มขึ้นของอาชญากรไซเบอร์ที่มุ่งเป้าไปที่แพลตฟอร์ม API สาธารณะในบริการทางการเงินทั่วโลก ตั้งแต่เดือนธันวาคม 2017 ถึงเดือนพฤศจิกายน 2019 Akamai พบเห็นการโจมตีละเมิดข้อมูลประจำตัว 85.42 พันล้านครั้ง ประมาณ 20% หรือ 16.55 พันล้านครั้ง เป็นการโจมตีชื่อโฮสต์ที่กำหนดเป็นปลายทาง API ในจำนวนนี้ 473.5 ล้านครั้ง มุ่งเป้าไปที่องค์กรในภาคบริการทางการเงิน[ 55 ]

เอกสารประกอบ API

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

เอกสารประกอบมีความสำคัญอย่างยิ่งต่อการพัฒนาและการบำรุงรักษาแอปพลิเคชันที่ใช้ API [ 56 ]เอกสารประกอบ API โดยทั่วไปจะอยู่ในไฟล์เอกสาร แต่ยังสามารถพบได้ในสื่อสังคมออนไลน์ เช่น บล็อก ฟอรัม และเว็บไซต์ถามตอบ[ 57 ]

ไฟล์เอกสารแบบดั้งเดิมมักจะนำเสนอผ่านระบบเอกสาร เช่น Javadoc หรือ Pydoc ซึ่งมีลักษณะและโครงสร้างที่สม่ำเสมอ อย่างไรก็ตาม ประเภทของเนื้อหาที่รวมอยู่ในเอกสารจะแตกต่างกันไปในแต่ละ API [ 58 ]

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

ข้อจำกัดและเงื่อนไขในการใช้งาน API ยังครอบคลุมอยู่ในเอกสารด้วย ตัวอย่างเช่น เอกสารสำหรับฟังก์ชัน API อาจระบุว่าพารามิเตอร์ของฟังก์ชันนั้นต้องไม่เป็นค่าว่าง และตัวฟังก์ชันเองก็ไม่ปลอดภัย ต่อการทำงานแบบมัลติเธรด [ 59 ] เนื่องจากเอกสาร API มักจะครอบคลุมมาก จึงเป็นความท้าทายสำหรับผู้เขียนในการอัปเดตเอกสารอยู่ เสมอและสำหรับผู้ใช้ในการอ่านอย่างละเอียด ซึ่งอาจส่งผลให้เกิดข้อผิดพลาดได้[ 51 ]

เอกสาร API สามารถเสริมด้วยข้อมูลเมตา เช่นคำอธิบายประกอบ Javaเมตาเดตาเหล่านี้สามารถใช้โดยคอมไพเลอร์ เครื่องมือ และสภาพ แวดล้อม รันไทม์เพื่อนำพฤติกรรมที่กำหนดเองหรือการจัดการที่กำหนดเองมาใช้[ 60 ]

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

บทความหลัก: Google LLC เทียบกับ Oracle America, Inc.

ในปี 2553 Oracle Corporation ฟ้อง Google เนื่องจากได้เผยแพร่การใช้งาน Java เวอร์ชันใหม่ที่ฝังอยู่ในระบบปฏิบัติการ Android [ 62 ] Google ไม่ได้รับอนุญาตใดๆ ในการสร้าง Java API ขึ้นมาใหม่ แม้ว่าจะได้รับอนุญาตให้กับโครงการ OpenJDK ที่คล้ายกันก็ตาม ผู้พิพากษาWilliam Alsupตัดสินใน คดี Oracle v. Googleว่า API ไม่สามารถจดลิขสิทธิ์ได้ในสหรัฐอเมริกา และหาก Oracle ชนะคดี จะเป็นการขยายการคุ้มครองลิขสิทธิ์ไปสู่ ​​"ชุดสัญลักษณ์ที่ใช้งานได้" และอนุญาตให้จดลิขสิทธิ์คำสั่งซอฟต์แวร์ง่ายๆ ได้

การยอมรับข้อเรียกร้องของ Oracle จะเป็นการอนุญาตให้ใครก็ตามจดลิขสิทธิ์โค้ดเวอร์ชันหนึ่งเพื่อดำเนินการระบบคำสั่ง และด้วยเหตุนี้จึงห้ามไม่ให้ผู้อื่นเขียนเวอร์ชันที่แตกต่างกันเพื่อดำเนินการคำสั่งเดียวกันทั้งหมดหรือบางส่วน[ 63 ] [ 64 ]

คำตัดสินของ Alsup ถูกพลิกกลับในปี 2014 ในการอุทธรณ์ต่อศาลอุทธรณ์แห่งวงจรของรัฐบาลกลางแม้ว่าคำถามที่ว่าการใช้ API ดังกล่าวถือเป็นการใช้ที่เป็นธรรม หรือ ไม่ยังคงไม่ได้รับการแก้ไข[ 65 ] [ 66 ]

ในปี 2016 หลังจากการพิจารณาคดีเป็นเวลาสองสัปดาห์ คณะลูกขุนตัดสินว่าการนำ Java API ของ Google มาใช้ใหม่นั้นถือเป็นการใช้งานโดยชอบธรรมแต่ Oracle สาบานว่าจะอุทธรณ์คำตัดสิน[ 67 ] Oracle ชนะการอุทธรณ์ โดยศาลอุทธรณ์แห่งรัฐบาลกลางตัดสินว่าการใช้ API ของ Google ไม่เข้าข่ายการใช้งานโดยชอบธรรม[ 68 ]ในปี 2019 Google ยื่นอุทธรณ์ต่อศาลฎีกาแห่งสหรัฐอเมริกาเกี่ยวกับทั้งคำตัดสินเรื่องลิขสิทธิ์และการใช้งานโดยชอบธรรม และศาลฎีกาได้อนุมัติการพิจารณาคดี[ 69 ]เนื่องจากการระบาดของโรคโควิด-19การพิจารณาคดีด้วยวาจาจึงถูกเลื่อนออกไปจนถึงเดือนตุลาคม 2020 [ 70 ]

ศาลฎีกาตัดสินคดีให้เป็นไปใน favor ของ Google [ 71 ]

ตัวอย่าง

หมวดหมู่หลัก: อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน

ดูเพิ่มเติม

เอกสารอ้างอิง

  1. Reddy, Martin (2011). การออกแบบ API สำหรับ C++ . Elsevier Science. หน้า 1. ISBN 9780123850041.
  2. Lane, Kin (10 ตุลาคม 2019). "บทนำเกี่ยวกับ API: ประวัติของ API" . Postman . สืบค้นเมื่อ18 กันยายน 2020 . เมื่อคุณได้ยินคำย่อ "API" หรือคำเต็มว่า "Application Programming Interface" มักจะหมายถึงวิธีการสมัยใหม่ของเรา ซึ่งเราใช้ HTTP เพื่อให้เข้าถึงข้อมูลที่เครื่องอ่านได้ในรูปแบบ JSON หรือ XML ซึ่งมักเรียกง่ายๆ ว่า "web API" API มีมานานเกือบเท่ากับการคำนวณ แต่ web API สมัยใหม่เริ่มเป็นรูปเป็นร่างในช่วงต้นทศวรรษ 2000 
  3. Pedro, Bruno (2024). การสร้างผลิตภัณฑ์ API: การออกแบบ การใช้งาน การเผยแพร่ และการบำรุงรักษาผลิตภัณฑ์ API ที่ตรงกับความต้องการของผู้ใช้สำนักพิมพ์ Packt หน้า 4 ISBN  9781837638536.
  4.  Biehl, Matthias (2016). การออกแบบ API แบบ RESTful . สำนักพิมพ์ API-University. หน้า 10. ISBN  9781514735169.
  5. Clarke, Steven (2004). "การวัดความสามารถในการใช้งาน API" . Dr. Dobb's . สืบค้นเมื่อ29 กรกฎาคม 2016 .
  6.  Jin, Brenda; Sahni, Saurabh; Shevat, Amir (2018). "คำนำ". การออกแบบ Web API: การสร้าง API ที่นักพัฒนาชื่นชอบ . O'Reilly Media. ISBN  9781492026877.
  7.  Geewax, JJ (2021). รูปแบบการออกแบบ API . Manning. หน้า 6. ISBN  9781638350330.
  8.  Jacobson, Daniel; Brail, Greg; Woods, Dan (2011). API: คู่มือกลยุทธ์ . O'Reilly Media. หน้า 4. ISBN  9781449321642.
  9. สถาปัตยกรรมฐานข้อมูล – การประชุมเชิงปฏิบัติการเพื่อศึกษาความเป็นไปได้ (รายงาน) วอชิงตัน ดี.ซี.: กระทรวงพาณิชย์สหรัฐอเมริกา สำนักงานมาตรฐานแห่งชาติ เมษายน 1981 หน้า  45–47 hdl : 2027/mdp.39015077587742 . LCCN 81600004 . เอกสารพิเศษของ NBS 500-76 . สืบค้นเมื่อ18 กันยายน 2020 .  
  10. Bloch, Joshua (8 สิงหาคม พ.ศ. 2561) ประวัติโดยย่อที่มีความคิดเห็นของ API (คำพูด) คิวคอน ซานฟรานซิสโก: InfoQ สืบค้นเมื่อวันที่ 18 กันยายน 2020 .
  11. Cotton, Ira W.; Greatorex, Frank S. (ธันวาคม 1968). "โครงสร้างข้อมูลและเทคนิคสำหรับกราฟิกคอมพิวเตอร์ระยะไกล" . AFIPS '68: รายงานการประชุมร่วมคอมพิวเตอร์ฤดูใบไม้ร่วง วันที่ 9–11 ธันวาคม 1968 . AFIPS 1968 การประชุมร่วมคอมพิวเตอร์ฤดูใบไม้ร่วง เล่มที่ 1. ซานฟรานซิสโก แคลิฟอร์เนีย: สมาคมเครื่องจักรคำนวณ หน้า  533–544 . doi : 10.1145/1476589.1476661 . ISBN  978-1450378994. OCLC  1175621908 .
  12. "อินเทอร์เฟซโปรแกรมแอปพลิเคชัน"พจนานุกรมภาษาอังกฤษอ็อกซ์ฟอร์ด (ฉบับออนไลน์) สำนักพิมพ์มหาวิทยาลัยอ็อกซ์ฟอร์ด (ต้องสมัครสมาชิกหรือเป็นสมาชิกของสถาบันที่เข้าร่วมโครงการ )
  13. Date, CJ (2019). EF Codd และทฤษฎีเชิงสัมพันธ์: การทบทวนและวิเคราะห์งานเขียนฐานข้อมูลที่สำคัญของ Codd อย่างละเอียด Lulu.com. หน้า 135. ISBN  978-1684705276.
  14.  Date, CJ; Codd, EF (มกราคม 1975). "แนวทางเชิงสัมพันธ์และเครือข่าย: การเปรียบเทียบอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน"ใน Randall Rustin (บรรณาธิการ). รายงานการประชุมเชิงปฏิบัติการ ACM-SIGMOD ประจำปี 1974 ว่าด้วยการอธิบาย การเข้าถึง และการควบคุมข้อมูล SIGMOD Workshop 1974 เล่ม ที่ 2 แอนน์อาร์เบอร์ รัฐมิชิแกน: สมาคมเครื่องจักรคำนวณ หน้า  83–113 doi : 10.1145 /800297.811532 ISBN  978-1450374187. OCLC  1175623233 .
  15. Carl, Malamud (1990). การวิเคราะห์เครือข่ายโนเวลล์ . Van Nostrand Reinhold. หน้า 294. ISBN  978-0442003647.
  16. น เบรนดา; ซาห์นี, เศราบห์; เชวัต, อามีร์ (2018) การออกแบบ Web APIโอ ไรลีย์ มีเดียไอเอสบีเอ็น  9781492026877.
  17.  ฟิลดิง, รอย (2000). รูปแบบสถาปัตยกรรมและการ ออกแบบสถาปัตยกรรมซอฟต์แวร์บนเครือข่าย (ปริญญาเอก) สืบค้นเมื่อ18 กันยายน 2020
  18.  Dotsika, Fefie (สิงหาคม 2010). "Semantic APIs: การขยายขนาดไปสู่ ​​Semantic Web". International Journal of Information Management . 30 (4): 335– 342. doi : 10.1016/j.ijinfomgt.2009.12.003 .
  19.  Odersky, Martin; Spoon, Lex; Venners, Bill (10 ธันวาคม 2008). "การผสมผสาน Scala และ Java" . www.artima.com . สืบค้นเมื่อ29 กรกฎาคม 2016 .
  20.  de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto ; Filho, Waldemar Celes (1994). "การออกแบบและการนำภาษาสำหรับการขยายแอปพลิเคชันไปใช้" . รายงานการประชุมสัมมนาซอฟต์แวร์และฮาร์ดแวร์แห่งบราซิล ครั้งที่ XXIหน้า  273–284 . CiteSeerX 10.1.1.47.5194 . S2CID 59833827. สืบค้นเมื่อ29 กรกฎาคม 2016 .   
  21.  Sintes, Tony (13 กรกฎาคม 2544). "API ของ Java คืออะไรกันแน่?" . JavaWorld . สืบค้นเมื่อ18 กรกฎาคม 2563 .
  22.  Winters, Titus; Tom Manshreck; Hyrum Wright, บรรณาธิการ (2020). วิศวกรรมซอฟต์แวร์ที่ Google: บทเรียนที่ได้จากการเขียนโปรแกรมตลอดเวลา . เซบาสโตโพล, แคลิฟอร์เนีย: O'Reilly Media. ISBN  9781492082798. OCLC  1144086840 .
  23.  Mastrangelo, Luis; Ponzanelli, Luca; Mocci, Andrea; Lanza, Michele; Hauswirth, Matthias; Nystrom, Nathaniel (2015-10-23). ​​"ใช้งานด้วยความเสี่ยงของคุณเอง: API ที่ไม่ปลอดภัยของ Java ในการใช้งานจริง". รายงานการประชุมนานาชาติ ACM SIGPLAN ประจำปี 2015 ว่าด้วยการเขียนโปรแกรมเชิงวัตถุ ระบบ ภาษา และแอปพลิเคชันนิวยอร์ก สหรัฐอเมริกา: สมาคมเครื่องจักรคำนวณ หน้า  695–710 . doi : 10.1145/2814270.2814313 . ISBN  978-1-4503-3689-5.
  24.  Emery, David. "มาตรฐาน, API, อินเทอร์เฟซ และการเชื่อมต่อ" . Acm.org. เก็บถาวรจากต้นฉบับเมื่อ 2015-01-16 . เรียกดูเมื่อ2016-08-08 .
  25. "F2PY.org" . F2PY.org . สืบค้นเมื่อ2011-12-18 .
  26.  ฟาวเลอร์, มาร์ติน. "การกลับด้านการควบคุม "
  27.  ฟายาด, โมฮาเหม็ด. "กรอบงานแอปพลิเคชันเชิงวัตถุ" .
  28.  Lewine, Donald A. (1991). คู่มือโปรแกรมเมอร์ POSIX . O'Reilly & Associates, Inc. หน้า 1. ISBN  9780937175736สืบค้นข้อมูลเมื่อ วัน ที่2 สิงหาคม 2559
  29.  West, Joel; Dedrick, Jason (2001). "การกำหนดมาตรฐานโอเพนซอร์ส: การเติบโตของ Linux ในยุคเครือข่าย" (PDF)ความรู้ เทคโนโลยี และนโยบาย 14 ( 2): 88– 112. doi : 10.1007/PL00022278 สืบค้นเมื่อ 2 สิงหาคม 2016
  30.  ไมโครซอฟต์ (ตุลาคม 2544). "การสนับสนุนสำหรับ Windows XP" . ไมโครซอฟต์. หน้า 4. เก็บถาวรจากต้นฉบับเมื่อ 26 กันยายน 2552.
  31.  บาร์นีย์, ดักลาส (2 พฤศจิกายน 1987). "การทรงตัวบนเส้นลวดแห่งความสำเร็จของไมโครซอฟต์" . คอมพิวเตอร์เวิลด์ . เล่มที่ XXI, ฉบับที่ 44. หน้า SR15 . สืบค้นเมื่อ8 มิถุนายน 2025 .
  32.  บาร์นีย์, ดักลาส (7 กรกฎาคม 1986). "การเลือกปฏิบัติและบริษัทขนาดเล็ก" . คอมพิวเตอร์เวิลด์ . เล่มที่ 20, ฉบับที่ 27. หน้า 45, 50 . สืบค้นเมื่อ13 มกราคม 2026 .
  33.  Gates, Bill; Manzi, Jim; Esber, Ed (2 พฤศจิกายน 1987). "การถกเถียงเรื่องซอฟต์แวร์ครั้งยิ่งใหญ่" . Computerworld (บทสัมภาษณ์). เล่มที่ XXI, ฉบับที่ 44. สัมภาษณ์โดย Paul Gillin. หน้า SR7 . สืบค้นเมื่อ8 มิถุนายน 2025 .
  34. "บทนำ LSB" . มูลนิธิลินุกซ์. 21 มิถุนายน 2012. เก็บถาวรจากต้นฉบับเมื่อ 2 เมษายน 2015. เรียกดูเมื่อ27 มีนาคม 2015 .
  35.  Stoughton, Nick (เมษายน 2548). "การอัปเดตเกี่ยวกับมาตรฐาน" (PDF) . USENIX . สืบค้นเมื่อ4 มิถุนายน 2552 .
  36.  Bierhoff, Kevin (23 เมษายน 2552). "การปฏิบัติตามโปรโตคอล API ในซอฟต์แวร์เชิงวัตถุ" (PDF) . สถาบันวิจัยซอฟต์แวร์ CMU . สืบค้นเมื่อ29 กรกฎาคม 2559 .
  37.  Wilson, M. Jeff (10 พฤศจิกายน 2000). "เรียนรู้การใช้งานพร็อกซีและ RMI อย่างชาญฉลาด" . JavaWorld . สืบค้นเมื่อ18 กรกฎาคม 2020 .
  38.  Henning, Michi; Vinoski, Steve (1999). การเขียนโปรแกรม CORBA ขั้นสูงด้วย C++ Addison - Wesley ISBN  978-0201379273สืบค้นข้อมูลเมื่อ วัน ที่16 มิถุนายน 2558
  39. "การแปลงเป็น API" (PDF) . www.hcltech.com . สิงหาคม 2557
  40.  Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). "Services Mashups: The New Generation of Web Applications" . IEEE Internet Computing . 12 (5). IEEE: 13– 15. Bibcode : 2008IIC....12e..13B . doi : 10.1109/MIC.2008.110 . สืบค้นเมื่อ2019-10-01 .
  41.  Niccolai, James (2008-04-23), "แล้ว Enterprise Mashup คืออะไรกันแน่?" , PC World , เก็บถาวรจากต้นฉบับเมื่อ 2017-10-10 , เรียกดูเมื่อ 2017-09-17
  42.  Parr, Ben (21 พฤษภาคม 2009). "วิวัฒนาการของ API สื่อสังคมออนไลน์" . Mashable . สืบค้นเมื่อ26 กรกฎาคม 2016 .
  43. "GET trends/place" . developer.twitter.com . สืบค้นเมื่อ2020-04-30 .
  44.  Parnas, DL (1972). "เกี่ยวกับเกณฑ์ที่จะใช้ในการแยกส่วนระบบออกเป็นโมดูล" (PDF) . Communications of the ACM . 15 (12): 1053– 1058. doi : 10.1145/361598.361623 . S2CID 53856438 .  
  45.  Garlan, David; Shaw, Mary (มกราคม 1994). "บทนำเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์" (PDF) . ความก้าวหน้าในวิศวกรรมซอฟต์แวร์และวิศวกรรมความรู้ . 1 . สืบค้นเมื่อ8 สิงหาคม 2016 .
  46.  de Ternay, Guerric (10 ตุลาคม 2015). "ระบบนิเวศทางธุรกิจ: การสร้างปราการทางเศรษฐกิจ" . BoostCompanies . เก็บถาวรจากต้นฉบับเมื่อ 17 กันยายน 2016 . สืบค้นเมื่อ1 กุมภาพันธ์ 2016 .
  47.  บอยด์, มาร์ค (21 กุมภาพันธ์ 2014). "ส่วนตัว พันธมิตร หรือสาธารณะ: กลยุทธ์ API ใดดีที่สุดสำหรับธุรกิจ?" . ProgrammableWeb . สืบค้นเมื่อ2 สิงหาคม 2016 .
  48.  Weissbrot, Alison (7 กรกฎาคม 2016). "API บริการรถยนต์มีอยู่ทุกหนทุกแห่ง แต่แอปพันธมิตรจะได้อะไรจากสิ่งนี้?" . AdExchanger .
  49. "เอกสารประกอบการใช้งาน Cloudflare API v4" . cloudflare . 25 กุมภาพันธ์ 2020 . สืบค้นเมื่อ27 กุมภาพันธ์ 2020 .
  50.  Liew, Zell (17 มกราคม 2018). "API บริการรถยนต์มีอยู่ทุกหนทุกแห่ง แต่แอปพันธมิตรจะได้อะไรจากสิ่งนี้" . Smashing Magazine . สืบค้นเมื่อ27 กุมภาพันธ์ 2020 .
  51. Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). การศึกษาเชิงประจักษ์เกี่ยวกับการวิวัฒนาการของเอกสารประกอบ APIการประชุมวิชาการนานาชาติว่าด้วยแนวทางพื้นฐานทางวิศวกรรมซอฟต์แวร์ Lecture Notes in Computer Science. Vol. 6603. หน้า  416–431 . doi : 10.1007/978-3-642-19811-3_29 . ISBN  978-3-642-19810-6สืบค้นข้อมูลเมื่อ วัน ที่22 กรกฎาคม 2559
  52.  google/guava: ไลบรารีหลักของ Google สำหรับ Javaบน GitHub
  53.  Oracle. "วิธีการและเวลาที่ควรยกเลิกการใช้งาน API" . เอกสารประกอบ Java SE . สืบค้นเมื่อ2 สิงหาคม 2016 .
  54.  Mendez, Diego; Baudry, Benoit; Monperrus, Martin (2013). หลักฐานเชิงประจักษ์ของความหลากหลายขนาดใหญ่ในการใช้งาน API ของซอฟต์แวร์เชิงวัตถุ 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM). หน้า  43–52 . arXiv : 1307.4062 . doi : 10.1109/SCAM.2013.6648183 . ISBN  978-1-4673-5739-5. S2CID  6890739 .
  55.  Takanashi, Dean (19 กุมภาพันธ์ 2020). "Akamai: อาชญากรไซเบอร์กำลังโจมตี API ของบริษัทบริการทางการเงิน" . Venture Beat . สืบค้นเมื่อ27 กุมภาพันธ์ 2020 .
  56.  Dekel, Uri; Herbsleb, James D. (พฤษภาคม 2009). " การปรับปรุงความสามารถในการใช้งานเอกสาร API ด้วยการผลักดันความรู้" สถาบันวิจัยซอฟต์แวร์ คณะวิทยาการคอมพิวเตอร์CiteSeerX 10.1.1.446.4214  
  57.  Parnin, Chris; Treude, Cristoph (พฤษภาคม 2011). "การวัดเอกสาร API บนเว็บ" . รายงานการประชุมเชิงปฏิบัติการนานาชาติครั้งที่ 2 เรื่อง Web 2.0 สำหรับวิศวกรรมซอฟต์แวร์ . หน้า  25– 30. doi : 10.1145/1984701.1984706 . ISBN  9781450305952S2CID 17751901 สืบค้นเมื่อ  22 กรกฎาคม 2016
  58.  Maalej, Waleed; Robillard, Martin P. (กันยายน 2012). "รูปแบบความรู้ในเอกสารอ้างอิง API" (PDF) . IEEE Transactions on Software Engineering . 39 (9): 1264– 1282. doi : 10.1109/TSE.2013.12 . สืบค้นเมื่อ22 กรกฎาคม 2016 .
  59.  Monperrus, Martin; Eichberg, Michael; Tekes, Elif; Mezini, Mira (3 ธันวาคม 2011). "นักพัฒนาควรตระหนักถึงอะไรบ้าง? การศึกษาเชิงประจักษ์เกี่ยวกับแนวทางของเอกสาร API" วิศวกรรมซอฟต์แวร์เชิงประจักษ์17 (6): 703– 737. arXiv : 1205.6363 . doi : 10.1007/s10664-011-9186-4 . S2CID 8174618 .  
  60. "คำอธิบายประกอบ" . ซัน ไมโครซิสเต็มส์ . เก็บถาวรจากต้นฉบับเมื่อ 25 กันยายน 2011 . เรียกดูเมื่อ30 กันยายน 2011 . .
  61.  Bruch, Marcel; Mezini, Mira; Monperrus, Martin (2010). การขุดค้นคำสั่งย่อยคลาสเพื่อปรับปรุงการนำเฟรมเวิร์กกลับมาใช้ใหม่การประชุมเชิงปฏิบัติการ IEEE ครั้งที่ 7 ว่าด้วยการขุดค้นคลังซอฟต์แวร์ (MSR 2010) หน้า  141–150 . CiteSeerX 10.1.1.434.15 . doi : 10.1109/msr.2010.5463347 . ISBN   978-1-4244-6802-7. S2CID  1026918 .
  62. "Oracle และจุดจบของการเขียนโปรแกรมอย่างที่เรารู้จัก" . DrDobbs. 2012-05-01 . สืบค้นเมื่อ2012-05-09 .
  63. "API ไม่สามารถจดลิขสิทธิ์ได้ ผู้พิพากษากล่าวในคดี Oracle" TGDaily. 2012-06-01. เก็บถาวรจากต้นฉบับเมื่อ 2020-07-31 . เรียกดูเมื่อ2012-12-06 .
  64. "Oracle America, Inc. ปะทะ Google Inc." (PDF) . Wired . 31 พฤษภาคม 2012 . สืบค้นเมื่อ22 กันยายน 2013 .
  65. "Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014" . Justia Law .
  66.  Rosenblatt, Seth (9 พฤษภาคม 2014). "ศาลตัดสินเข้าข้าง Oracle ในคดีอุทธรณ์สิทธิบัตร Java ของ Android" . CNET . สืบค้นเมื่อ10 พฤษภาคม 2014 .
  67. "Google เอาชนะ Oracle – Android ใช้ API ของ Java อย่าง "เป็นธรรม"" Ars Technica . 2016-05-26 . สืบค้นเมื่อ2016-07-28 .
  68.  Decker, Susan (27 มีนาคม 2018). "Oracle ชนะคดีฟ้องร้อง Google มูลค่าพันล้านดอลลาร์อีกครั้ง" . Bloomberg Businessweek . สืบค้นเมื่อ27 มีนาคม 2018 .
  69.  ลี, ทิโมธี (25 มกราคม 2019). "Google ขอให้ศาลฎีกาเพิกถอนคำตัดสินที่ผิดพลาดเกี่ยวกับลิขสิทธิ์ API" . Ars Technica . สืบค้นเมื่อ8 กุมภาพันธ์ 2019 .
  70.  vkimber (2020-09-28). "Google LLC กับ Oracle America, Inc" . LII / สถาบันข้อมูลทางกฎหมาย. สืบค้นเมื่อ2021-03-06 .
  71. "ศาลฎีกาแห่งสหรัฐอเมริกา เลขที่ 18–956, GOOGLE LLC ผู้ร้อง กับ ORACLE AMERICA, INC" (PDF) 5 เมษายน 2021

อ่านเพิ่มเติม

ข้อความต้นฉบับ
An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.[1] A document or standard that describes how to build such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation.
ให้คะแนนคำแปลนี้
เราจะใช้ความคิดเห็นของคุณเพื่อปรับปรุง Google แปลภาษาnull

ความคิดเห็น

แสดงความคิดเห็น

โพสต์ยอดนิยมจากบล็อกนี้

นิติมาลัย

 <?xml version="1.0" encoding="utf-8"?> <rss version="2.0" xml:base="https://www.drthawip.com" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel>  <title>สถาบันนิติธรรมาลัย</title>www.law.go.th  <link>https://www.drthawip.com</link>  <description></description>  <language>th</language> <item>  <title>ประมวลกฎหมายอาญา</title>com.google.android.app.docs.editors.docs  <link>https://www.drthawip.com/node/1788</link>com.google.android.app.docs.editors.docs  <description>&lt;div class=&quot;field field-name-body field-type-text-with-summary field-label-hidden&quot;&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; property=&quot;content:encoded&quot;&gt;&lt;p&gt;&lt;span style=&quot;color: #000000;&quot; data-mce-mark=&quot...
อ่านเพิ่มเติม

การไฟฟ้า

รูปภาพ
 https://leic.coj.go.th/ FQG5+HMX ตำบลกุดป่อง อำเภอเมืองเลย เลย 42000 https://government14.jimdofree.com/ https://tcd261.blogspot.com/2025/04/blog-post.html?m=1 Skip to main content itch.io Browse Games Game Jams Upload Game Developer Logs Community Log in Game Off 2025 Hosted by  GitHub ,  Lee Reilly  ·  #GitHubGameOff 731 Entries 8,627 Ratings Overview Submissions Community 435 Screenshots Submission feed Submissions open from  November 2nd 2025 at 3:37 AM  to  December 2nd 2025 at 4:37 AM Voting ends in 17 days 7 hours 32 minutes 59 seconds Submission is closed and voting is now in progress Game Off is an annual game jam challenging individuals and teams to build a game during the month of November. Use whatever programming languages, game engines, or libraries you like.  This year's theme is  WAVES . wave /weɪv/ Noun A moving ridge on the surface of a liquid (for example, ocean waves or coffee ripples). A repeating pattern of mo...
อ่านเพิ่มเติม

กรมการปกครองจังหวัดเลย

รูปภาพ
  https://leic.coj.go.th/ https://government14.jimdofree.com/ https://tcd261.blogspot.com/2025/04/blog-post.html?m=1 Skip to main content itch.io Browse Games Game Jams Upload Game Developer Logs Community Log in Game Off 2025 Hosted by  GitHub ,  Lee Reilly  ·  #GitHubGameOff 731 Entries 8,627 Ratings Overview Submissions Community 435 Screenshots Submission feed Submissions open from  November 2nd 2025 at 3:37 AM  to  December 2nd 2025 at 4:37 AM Voting ends in 17 days 7 hours 32 minutes 59 seconds Submission is closed and voting is now in progress Game Off is an annual game jam challenging individuals and teams to build a game during the month of November. Use whatever programming languages, game engines, or libraries you like.  This year's theme is  WAVES . wave /weɪv/ Noun A moving ridge on the surface of a liquid (for example, ocean waves or coffee ripples). A repeating pattern of motion, energy, or sound (for example, sound w...
อ่านเพิ่มเติม