Ⅰ 如何正確開發應用程序介面

在交互組件化軟體的世界裡，沒有比讓組件之間以及組件與移動設備和瀏覽器之間進行連接的應用程序介面（API）更重要的東西了。用恰當的方式開發出來的API，可幫助功能整合與開發者的忠誠；而用不當的方式開發則會危及整個項目。
有三種方式可助API開發走到正確的一邊：
了解應用和使用約束；
處理組件結構並綁定框架；
確保優雅地處理變更。
API把功能和服務暴露給開發者。API的使用方式及服務系列展示是初步設計的驅動力。在API開發中，開發者和架構師犯的其中一個最重大的錯誤是忽視自己的用戶。API設計能否很好地適應開發者、語言和其他API組成的生態體系是一個至關重要的問題。
常見的API設計問題
REST與SOAP之爭就是API約束集的一個例子。只要應用已經存在相互依賴的地方，新的API顯然應該與之協調一致。不那麼明顯的是大多數API是組件化和功能顯露趨勢的一部分。這種運動隨著時間遷移會讓一組API越來越朝向REST或SOAP的方向，因此要確保對這種遷移的預期。
架構師很容易會被遵循對象架構和框架綁定傷到。挑選合適的API設計很重要，因為讓開發者採用一個與其所開發應用的架構不匹配的介面是很困難的。應該注意的是RESTful API往往展現的是資源，而SOAP API展現的往往是遠程流程或過程。
一些協議過去往往將API與API用戶綁定在一起，且經常跟Web應用一起，這種協議往往是HTTP/HTTPS。HTTP的使用一般會配合超文本標記語言（Hypertext Markup Language）或XML語言的數據格式，或者在客戶端設備上用JSON或JavaScript，使得很容易就能通過API創建圖形用戶界面，但在瀏覽器訪問並非應用的意圖所在時就不合適。有的應用和API可能會使用特殊的TCP協議或UDP協議埠而非標準的Web埠80。盡管這能幫助將API流量與Web活動區分開來，但也有可能存在防火牆/安全方面的影響，需要進行特殊的系統配置才能要麼將API暴露出來，要麼在遠程使用它們。
API設計的一般規則
大多數的API可被視為由動詞與名片語成的語法。比方說，帶動詞的句子表示一項請求動作（get、put、delete），而名詞則表示與該動作相關的參數。總是生成一個狀態或結果變數是一個很好地做法，因為這能夠傳達出錯誤狀態或成功執行的信息。出錯狀態應該全面綜合，足以明白無誤地傳達出問題所在。
API的語義，即所提供功能的語法也很重要，因為API清晰表達其服務和參數的能力可減少開發者的錯誤。一個關鍵點是如果API代表的是一個有狀態的服務，那麼功能語義就應該是面向會話式的（尋找記錄、更新記錄、刪除記錄），這樣的有狀態屬性服務就可以很清楚了。
由此得出結論，如果在本例中更新和刪除功能是對上一次定位的數據元素進行操作的話，那麼更新和刪除功能不用提供自己的數據元素鍵，這是多餘的，但也會產生令開發者困惑的風險。另一方面，無狀態服務永遠都必須提供所有的數據，因為沒有可供推斷的會話上下文信息。
常見問題
更新或變更API導致的語法問題往往被忽視。API有兩端，變更過程會令其失去同步。有些架構師會在API裡面放一個版本變數來確保兩端預期的是相同的格式。API的伺服器端和客戶端至少都應該進行基本的驗證來防止變更導致語法不匹配，從而避免信息被弄亂或導致應用崩潰。
另一個常見問題與數據格式有關。XML是傳遞參數和交換信息最常用的方法，適用於REST和SOAP介面。但XML的處理卻是重負載的，對表達結構化數據最有價值。而REST中，JSON則因為更容易使用的同時還提供了一些在API開發中廣為採用和預期的特殊變數類型而受到喜愛。在API交換嚴格定義的數據元素時，JSON似乎是RESTful交換更好的選擇。
API測試往往集中在應用生命周期管理的過程中。有些測試正好是這個階段的，但是也應該有特殊單元測試流程，這些流程旨在驗證API，並確定API可優雅地執行，哪怕是數據存在錯誤的時候。API的數據綁定和類型定義越寬松，傳遞信息會導致隨後錯誤或崩潰的風險就越高。這正是為什麼對變數要進行嚴格約束，並對每一個API都要用一組數據進行測試之所以重要的原因。
API開發問題會毀了一個應用，這種破壞比幾乎任何其他類型的架構錯誤都要快、都要徹底。多花點時間在API設計上，以便能預計到當前的錯誤狀態，以及未來的變化，這些時間的投入是值得的。

Ⅱ API怎麼開發

API（Application Programming Interface,應用程序編程介面）是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟體或硬體得以訪問一組常式的能力，而又無需訪問源碼，或理解內部工作機制的細節。
API函數包含在Windows系統目錄下的動態連接庫文件中。Windows API是一套用來控制Windows的各個部件的外觀和行為的預先定義的Windows函數。用戶的每個動作都會引發一個或幾個函數的運行以告訴Windows發生了什麼。這在某種程度上很像Windows的天然代碼。而其他的語言只是提供一種能自動而且更容易的訪問API的方法。當你點擊窗體上的一個按鈕時，Windows會發送一個消息給窗體，VB獲取這個調用並經過分析後生成一個特定事件。
更易理解來說：Windows系統除了協調應用程序的執行、內存的分配、系統資源的管理外，同時他也是一個很大的服務中心。調用這個服務中心的各種服務(每一種服務就是一個函數)可以幫助應用程序達到開啟視窗、描繪圖形和使用周邊設備等目的，由於這些函數服務的對象是應用程序，所以稱之為Application Programming Interface，簡稱API 函數。WIN32 API也就是MicrosoftWindows 32位平台的應用程序編程介面。
凡是在 Windows工作環境底下執行的應用程序，都可以調用Windows API。
linux API

在linux中，用戶編程介面API遵循了UNIX中最流行的應用編程界面標准---POSIX標准。POSIX標準是由IEEE和ISO/IEC共同開發的標准系統。該標准基於當時現有的UNIX實踐和經驗，描述了操作系統的系統調用編程介面API，用於保證應用程序可以在源程序一級上在多種操作系統上移植運行。這些系統調用編程介面主要是通過C庫（LIBC）來實現的。
開放平台

基於互聯網的應用正變得越來越普及，在這個過程中，有更多的站點將自身的資源開放給開發者來調用。對外提供的API 調用使得站點之間的內容關聯性更強，同時這些開放的平台也為用戶、開發者和中小網站帶來了更大的價值。
開放是目前的發展趨勢，越來越多的產品走向開放。目前的網站不能靠限制用戶離開來留住用戶，開放的架構反而更增加了用戶的粘性。在Web 2.0的浪潮到來之前，開放的API 甚至源代碼主要體現在桌面應用上，而現在越來越多的Web應用面向開發者開放了API。
具備分享、標准、去中心化、開放、模塊化的Web 2.0站點，在為使用者帶來價值的同時，更希望通過開放的API 來讓站點提供的服務擁有更大的用戶群和服務訪問數量。
站點在推出基於開放API 標準的產品和服務後，無需花費力氣做大量的市場推廣，只要提供的服務或應用出色易用，其他站點就會主動將開放API 提供的服務整合到自己的應用之中。同時，這種整合API 帶來的服務應用，也會激發更多富有創意的應用產生。
為了對外提供統一的API 介面，需要對開發者開放資源調用API 的站點提供開放統一的API介面環境，來幫助使用者訪問站點的功能和資源。
當然，開放API 的站點為第三方的開發者提供良好的社區支持也是很有意義的，這有助於吸引更多的技術人員參與到開放的開發平台中，並開發出更為有趣的第三方應用。
視頻雲技術提供商CC視頻開放API介面，用戶可以在自己的網站後台輕松完成視頻的上傳、視頻播放控制操作，並可批量獲取視頻及平台信息。
正如在"什麼是API"中所說,API函數包含在位於系統目錄下的DLL文件中。你可以自己輸入API函數的聲明，但VB提供了一種更簡單的方法,即使用API Text Viewer。 要想在你的工程中聲明API函數，只需運行API Text Viewer,打開Win32api.txt或MDB。如果你已經把它轉換成了資料庫的話，這樣可以加快速度。 使用預定義的常量和類型也是同樣的方法。 API除了有應用「應用程序介面」的意思外，還特指API的說明文檔，也稱為幫助文檔。
假設你想在你的窗體模塊中聲明一個函數，粘貼然後運行，VB會告訴你：編譯錯誤...Declare 語句不允許作為類或對象模塊中的Public(公共的) 成員。..看起來很糟糕，其實你需要做的只是在聲明前面添加一個Private(私有的)。不要忘了，可是這將使該函數只在該窗體模塊可用。. 在有些情況下，你會得到"不明確的名稱"這樣的提示，這是因為函數、常量或其他的什麼東西共用了一個名稱。由於絕大多數的函數都進行了別名化，亦即意味著你可以通過Alias子句使用其它的而不是他們原有的名稱，你只需簡單地改變一下函數名稱而它仍然可以正常運行。
遠程過程調用（RPC）：通過作用在共享數據緩存器上的過程（或任務）實現程序間的通信。
標准查詢語言（SQL）：是標準的訪問數據的查詢語言，通過通用資料庫實現應用程序間的數據共享。
文件傳輸：文件傳輸通過發送格式化文件實現應用程序間數據共享。
信息交付：指松耦合或緊耦合應用程序間的小型格式化信息，通過程序間的直接通信實現數據共享。
當前應用於 API 的標准包括ANSI 標准SQL API。另外還有一些應用於其它類型的標准尚在制定之中。API 可以應用於所有計算機平台和操作系統。這些API 以不同的格式連接數據。每種數據格式要求以不同的數據命令和參數實現正確的數據通信，但同時也會產生不同類型的錯誤。因此，除了具備執行數據共享任務所需的知識以外，這些類型的API 還必須解決很多網路參數問題和可能的差錯條件，即每個應用程序都必須清楚自身是否有強大的性能支持程序間通信。相反由於這種API 只處理一種信息格式，所以該情形下的信息交付API 只提供較小的命令、網路參數以及差錯條件子集。正因為如此，交付API 方式大大降低了系統復雜性，所以當應用程序需要通過多個平台實現數據共享時，採用信息交付API 類型是比較理想的選擇。
API 介面屬於一種操作系統或程序介面，GUI介面屬於一種圖形操作系統。兩者都屬於直接用戶介面。有時公司會將 API 作為其公共開放系統。也就是說，公司制定自己的系統介面標准，當需要執行系統整合、自定義和程序應用等操作時，公司所有成員都可以通過該介面標准調用源代碼，該介面標准被稱之為開放式API。

Ⅲ 軟體介面的發展歷程

早在上個世紀的70年代，Digital Research公司的Gary Kildall為微型計算機首創了世界上第一個實用的軟體API。這個初生的API大致上有20多個對操作系統的簡單函數調用組成，這個操作系統就是CP/M――那時可是相當的簡單和粗糙，而同樣簡單的API卻讓整個計算機世界發生了重大變化。Kildall這個很有才氣的計算機專家希望自己設計的API能被其他科學工作者採用。至於商用方面的考慮可是想都沒想。而且，我們現在的產業現狀也證明：僅讓科學家們俱歡顏是不會在商業中賺到一分錢的！好在，比爾蓋茨認識到，用於應用程序開發人員而不是科學家的API絕對是商業軟體獲得成功的關鍵之一，這樣一來，情況就很不一樣了。
隨後由比爾·蓋茨等開發的MS-DOS操作系統全盤拷貝了CP/M及其API，並在這些API的基礎之上又增加了一些簡單特性，務實的比爾·蓋茨將Kildall的發明變成了巨大的商業應用並立刻讓MS-DOS的API在軟體開發中占據了主導地位。
然而，當微軟公司推出Windows操作系統的時候，系統的龐大API族就沒有拷貝Kildall的成果了，可是，事實證明這些微軟自己折騰出來的Windows API實在是糟糕的可以：醜陋的代碼、混亂的結構等等不一而足。但是，Windows採用了實用的偽多線程技術和高效的內存管理，特別是簡單易用的圖形界面立刻俘獲了一般用戶的忠心。大量的程序員也就隨之投入到Windows程序的開發中來，這些糟糕的API自然當仁不讓了。微軟花費了5年多的時間改進和發展早期的Windows並在最終壟斷了全球桌面操作系統市場。今天我們誰也離不開Windows API了，除非你不打算編寫支持Windows的軟體！
1988年，微軟購買了Alan Cooper開發的可視編程語言：Ruby。隨後微軟把Ruby和垂死的QuickBASIC語言組合起來創建了Visual Basic。Alan Cooper方面的Ruby實現了名為VBX的軟體API，這種API可以讓程序員動態地擴展Visual Basic功能，這一事實再次證明了軟體介面具有多大的重要性。VBX介面也就是目前火熱的組件對象模型COM的前身。
在為微軟的勢力之外，Unix世界也發明了自己的API，這就是TCP/IP，有了它，網路之間就可以自由地通信了。TCP/IP首先在大學里獲得了普遍的歡迎，然後，到了20世紀90年代，Marc Andreessen瞄準那些不是程序員卻很想從使用計算機獲得好處的年輕人推出了世界上第一個Web瀏覽器：Mosaic，後來在此基礎上誕生了Netscape Navigator，可以說，正是Web和瀏覽器的發明，我們終於被帶到了信息時代。
最早的Navigator所能作的不外乎就是查找和顯示文件，這和Macintosh Finder乃至Windows Explorer也沒什麼兩樣，但是，正因為有了TCP/IP API，Netscape 就可以放眼於本機之外查找和顯示其他網路上的其他計算機中的文件。新世界豁然洞開。
整個90年代，Netscape就象流感病毒一樣滿世界到處擴散。到了現在計算機之間在通用API的努力下可以非常方便地相互通信，但幾乎沒有一個用戶會直接和這些TCP/IP介面交互。
如果沒有優秀的、符合時代潮流的API，什麼先進的技術都可能會不得不寂寞很長一段時間以等待命運的垂青。一旦成熟的API出現，軟體的前景也就能大致看到輪廓了。
舉個例子，不管是你身上的手機還是隨身攜帶的PDA――比如PalmPilot，它們其實都是處理能力不同的計算機而已，這兩種設備都裝備了短距無線（通常是紅外線）通信埠。可是，它們如何才能通過這些埠實現相互之間的通信呢？如果這些設備之間缺乏公用的API，你的手機就不可能和你的PDA實現通信。
今後會產生一種所謂的「陌生人服務」API，比方說，當你走在大街上的時候，你的手持設備，不管是手機、PDA還是筆記本電腦或者車載導航設備就會自動地和周圍設施通信，商店、辦公室、售貨機和其他人等等。
目前有幾家公司已經在致力於開發以上的通用API，其中最有希望的或許是Sun公司的Jini。但是，Jini的定位和以前的CP/M一樣，也是更多的把目標放在了計算機科學家而不是解決方案服務商上。
我們今天的軟體開發很大一部分是開發Web應用程序，驅動Web進步的是交互設計和商務模式而不是技術創新。從技術上說，Web領域的大開發商不會對Web本身挖掘太多，他們缺乏編寫大型、復雜程序的耐心。但是，反過來，這些大型廠商可以把其他開發商預先編寫的軟體組件組合起來，這樣，他們就比以往更多地依賴於為其編寫的軟體API。
總而言之，不管我們設計什麼API，最重要的是首先要弄明白我們在為什麼目標或者為誰在設計。這是一定要記得的關鍵點。只有在我們理解目標受眾的需求之後，我們才可能創建有用的API，才能實現恰當的用戶介面，才能讓不同人設計的不同軟體部分良好地集成。

Ⅳ app介面開發怎麼實現

  1. 找到第三方提供介面的文檔，按照文檔接入

  2. 在自己的伺服器上架設API介面

  3. 在自己的APP裡面接第三方介面的SDK

  4. 重新打包，完善功能即可！

Ⅳ 什麼叫軟體介面

  1. 計算機世界裡的介面這兩個字具有兩種眾所周知的含義：其一是指軟體本身的狹義專「介面」，屬比如各種軟體開發API等。其二則指的是人與軟體之間的交互界面。

  2. 把這種人-軟體之間的介面稱作「用戶界面」,也就是「UI」。這里要討論的前一種定義： 軟體不同部分之間的交互介面。通常就是所謂的API應用程序編程介面，其表現的形式是源代碼。API的發明和發展大大促進了計算機產業的進步，同時API幾乎決定著日常運算的各個方面。

  3. 大多數程序員秉承為軟體用戶設計優秀的用戶界面思想，這一點早已深入人心。可是，另一方面，如何實現合理的軟體API卻只為少數人所重視。歷史證明，所有在應用上獲得成功的軟體或者Web應用無一不是首先在API的設計上滿足了用戶的需求，即便這些用戶幾乎從不直接使用這些API。

Ⅵ 怎麼快速開發一個介面

首先你是研發的專業，包括你會嗯，代碼或怎麼怎麼樣做這些才可以，你不是專業的，根本弄不出來。

Ⅶ 如何開發api介面

API（Application Programming Interface,應用程序編程介面）是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟體或硬體得以訪問一組常式的能力，而又無需訪問源碼，或理解內部工作機制的細節。
API函數包含在Windows系統目錄下的動態連接庫文件中。Windows API是一套用來控制Windows的各個部件的外觀和行為的預先定義的Windows函數。用戶的每個動作都會引發一個或幾個函數的運行以告訴Windows發生了什麼。這在某種程度上很像Windows的天然代碼。而其他的語言只是提供一種能自動而且更容易的訪問API的方法。當你點擊窗體上的一個按鈕時，Windows會發送一個消息給窗體，VB獲取這個調用並經過分析後生成一個特定事件。
更易理解來說：Windows系統除了協調應用程序的執行、內存的分配、系統資源的管理外，同時他也是一個很大的服務中心。調用這個服務中心的各種服務(每一種服務就是一個函數)可以幫助應用程序達到開啟視窗、描繪圖形和使用周邊設備等目的，由於這些函數服務的對象是應用程序，所以稱之為Application Programming Interface，簡稱API 函數。WIN32 API也就是MicrosoftWindows 32位平台的應用程序編程介面。
凡是在 Windows工作環境底下執行的應用程序，都可以調用Windows API。
linux API

在linux中，用戶編程介面API遵循了UNIX中最流行的應用編程界面標准---POSIX標准。POSIX標準是由IEEE和ISO/IEC共同開發的標准系統。該標准基於當時現有的UNIX實踐和經驗，描述了操作系統的系統調用編程介面API，用於保證應用程序可以在源程序一級上在多種操作系統上移植運行。這些系統調用編程介面主要是通過C庫（LIBC）來實現的。
2開放平台

基於互聯網的應用正變得越來越普及，在這個過程中，有更多的站點將自身的資源開放給開發者來調用。對外提供的API 調用使得站點之間的內容關聯性更強，同時這些開放的平台也為用戶、開發者和中小網站帶來了更大的價值。
開放是目前的發展趨勢，越來越多的產品走向開放。目前的網站不能靠限制用戶離開來留住用戶，開放的架構反而更增加了用戶的粘性。在Web 2.0的浪潮到來之前，開放的API 甚至源代碼主要體現在桌面應用上，而現在越來越多的Web應用面向開發者開放了API。
具備分享、標准、去中心化、開放、模塊化的Web 2.0站點，在為使用者帶來價值的同時，更希望通過開放的API 來讓站點提供的服務擁有更大的用戶群和服務訪問數量。
站點在推出基於開放API 標準的產品和服務後，無需花費力氣做大量的市場推廣，只要提供的服務或應用出色易用，其他站點就會主動將開放API 提供的服務整合到自己的應用之中。同時，這種整合API 帶來的服務應用，也會激發更多富有創意的應用產生。
為了對外提供統一的API 介面，需要對開發者開放資源調用API 的站點提供開放統一的API介面環境，來幫助使用者訪問站點的功能和資源。
當然，開放API 的站點為第三方的開發者提供良好的社區支持也是很有意義的，這有助於吸引更多的技術人員參與到開放的開發平台中，並開發出更為有趣的第三方應用。
視頻雲技術提供商CC視頻開放API介面，用戶可以在自己的網站後台輕松完成視頻的上傳、視頻播放控制操作，並可批量獲取視頻及平台信息。
正如在"什麼是API"中所說,API函數包含在位於系統目錄下的DLL文件中。你可以自己輸入API函數的聲明，但VB提供了一種更簡單的方法,即使用API Text Viewer。 要想在你的工程中聲明API函數，只需運行API Text Viewer,打開Win32api.txt或MDB。如果你已經把它轉換成了資料庫的話，這樣可以加快速度。 使用預定義的常量和類型也是同樣的方法。 API除了有應用「應用程序介面」的意思外，還特指API的說明文檔，也稱為幫助文檔。
假設你想在你的窗體模塊中聲明一個函數，粘貼然後運行，VB會告訴你：編譯錯誤...Declare 語句不允許作為類或對象模塊中的Public(公共的) 成員。..看起來很糟糕，其實你需要做的只是在聲明前面添加一個Private(私有的)。不要忘了，可是這將使該函數只在該窗體模塊可用。. 在有些情況下，你會得到"不明確的名稱"這樣的提示，這是因為函數、常量或其他的什麼東西共用了一個名稱。由於絕大多數的函數都進行了別名化，亦即意味著你可以通過Alias子句使用其它的而不是他們原有的名稱，你只需簡單地改變一下函數名稱而它仍然可以正常運行。
遠程過程調用（RPC）：通過作用在共享數據緩存器上的過程（或任務）實現程序間的通信。
標准查詢語言（SQL）：是標準的訪問數據的查詢語言，通過通用資料庫實現應用程序間的數據共享。
文件傳輸：文件傳輸通過發送格式化文件實現應用程序間數據共享。
信息交付：指松耦合或緊耦合應用程序間的小型格式化信息，通過程序間的直接通信實現數據共享。
當前應用於 API 的標准包括ANSI 標准SQL API。另外還有一些應用於其它類型的標准尚在制定之中。API 可以應用於所有計算機平台和操作系統。這些API 以不同的格式連接數據。每種數據格式要求以不同的數據命令和參數實現正確的數據通信，但同時也會產生不同類型的錯誤。因此，除了具備執行數據共享任務所需的知識以外，這些類型的API 還必須解決很多網路參數問題和可能的差錯條件，即每個應用程序都必須清楚自身是否有強大的性能支持程序間通信。相反由於這種API 只處理一種信息格式，所以該情形下的信息交付API 只提供較小的命令、網路參數以及差錯條件子集。正因為如此，交付API 方式大大降低了系統復雜性，所以當應用程序需要通過多個平台實現數據共享時，採用信息交付API 類型是比較理想的選擇。
API 介面屬於一種操作系統或程序介面，GUI介面屬於一種圖形操作系統。兩者都屬於直接用戶介面。有時公司會將 API 作為其公共開放系統。也就是說，公司制定自己的系統介面標准，當需要執行系統整合、自定義和程序應用等操作時，公司所有成員都可以通過該介面標准調用源代碼，該介面標准被稱之為開放式API。

Ⅷ 什麼是軟體介面

軟體介面軟體的未來其實在很大程度上要指望軟體介面的前景如何。我們知道，計算機世界裡的介面這兩個字具有兩種眾所周知的含義：其一是指軟體本身的狹義「介面」，比如各種軟體開發API等。其二則指的是人與軟體之間的交互界面。我們把這種人-軟體之間的介面稱作「用戶界面」,也就是「UI」。這里要討論的前一種定義： 軟體不同部分之間的交互介面。通常就是所謂的API――應用程序編程介面，其表現的形式是源代碼。API的發明和發展大大促進了計算機產業的進步，同時API幾乎決定著日常運算的各個方面。大多數程序員秉承為軟體用戶設計優秀的用戶界面思想，這一點早已深入人心。可是，另一方面，如何實現合理的軟體API卻只為少數人所重視。歷史證明，所有在應用上獲得成功的軟體或者Web應用無一不是首先在API的設計上滿足了用戶的需求，即便這些用戶幾乎從不直接使用這些API！早在上個世紀的70年代，Digital Research公司的Gary Kildall為微型計算機首創了世界上第一個實用的軟體API。這個初生的API大致上有20多個對操作系統的簡單函數調用組成，這個操作系統就是CP/M――那時可是相當的簡單和粗糙，而同樣簡單的API卻讓整個計算機世界發生了重大變化。Kildall這個很有才氣的計算機專家希望自己設計的API能被其他科學工作者採用。至於商用方面的考慮可是想都沒想。而且，我們現在的產業現狀也證明：僅讓科學家們俱歡顏是不會在商業中賺到一分錢的！好在，比爾?蓋茨認識到，用於應用程序開發人員而不是科學家的API絕對是商業軟體獲得成功的關鍵之一，這樣一來，情況就很不一樣了。隨後由比爾?蓋茨等開發的MS-DOS操作系統全盤拷貝了CP/M及其API，並在這些API的基礎之上又增加了一些簡單特性，務實的比爾?蓋茨將Kildall的發明變成了巨大的商業應用並立刻讓MS-DOS的API在軟體開發中占據了主導地位。然而，當微軟公司推出Windows操作系統的時候，系統的龐大API族就沒有拷貝Kildall的成果了，可是，事實證明這些微軟自己折騰出來的Windows API實在是糟糕的可以：醜陋的代碼、混亂的結構等等不一而足。但是，Windows採用了實用的偽多線程技術和高效的內存管理，特別是簡單易用的圖形界面立刻俘獲了一般用戶的忠心。大量的程序員也就隨之投入到Windows程序的開發中來，這些糟糕的API自然當仁不讓了。微軟花費了5年多的時間改進和發展早期的Windows並在最終壟斷了全球桌面操作系統市場。今天我們誰也離不開Windows API了，除非你不打算編寫支持Windows的軟體！1988年，微軟購買了Alan Cooper開發的可視編程語言：Ruby。隨後微軟把Ruby和垂死的QuickBASIC語言組合起來創建了Visual Basic。Alan Cooper方面的Ruby實現了名為VBX的軟體API，這種API可以讓程序員動態地擴展Visual Basic功能，這一事實再次證明了軟體介面具有多大的重要性。VBX介面也就是目前火熱的組件對象模型COM的前身。在為微軟的勢力之外，Unix世界也發明了自己的API，這就是TCP/IP，有了它，網路之間就可以自由地通信了。TCP/IP首先在大學里獲得了普遍的歡迎，然後，到了20世紀90年代，Marc Andreessen瞄準那些不是程序員卻很想從使用計算機獲得好處的年輕人推出了世界上第一個Web瀏覽器：Mosaic，後來在此基礎上誕生了Netscape Navigator，可以說，正是Web和瀏覽器的發明，我們終於被帶到了信息時代。最早的Navigator所能作的不外乎就是查找和顯示文件，這和Macintosh Finder乃至Windows Explorer也沒什麼兩樣，但是，正因為有了TCP/IP API，Netscape 就可以放眼於本機之外查找和顯示其他網路上的其他計算機中的文件。新世界豁然洞開。整個90年代，Netscape就象流感病毒一樣滿世界到處擴散。到了現在計算機之間在通用API的努力下可以非常方便地相互通信，但幾乎沒有一個用戶會直接和這些TCP/IP介面交互。如果沒有優秀的、符合時代潮流的API，什麼先進的技術都可能會不得不寂寞很長一段時間以等待命運的垂青。一旦成熟的API出現，軟體的前景也就能大致看到輪廓了。舉個例子，不管是你身上的手機還是隨身攜帶的PDA――比如PalmPilot，它們其實都是處理能力不同的計算機而已，這兩種設備都裝備了短距無線（通常是紅外線）通信埠。可是，它們如何才能通過這些埠實現相互之間的通信呢？如果這些設備之間缺乏公用的API，你的手機就不可能和你的PDA實現通信。今後會產生一種所謂的「陌生人服務」API，比方說，當你走在大街上的時候，你的手持設備，不管是手機、PDA還是筆記本電腦或者車載導航設備就會自動地和周圍設施通信，商店、辦公室、售貨機和其他人等等。目前有幾家公司已經在致力於開發以上的通用API，其中最有希望的或許是Sun公司的Jini。但是，Jini的定位和以前的CP/M一樣，也是更多的把目標放在了計算機科學家而不是解決方案服務商上。我們今天的軟體開發很大一部分是開發Web應用程序，驅動Web進步的是交互設計和商務模式而不是技術創新。從技術上說，Web領域的大開發商不會對Web本身挖掘太多，他們缺乏編寫大型、復雜程序的耐心。但是，反過來，這些大型廠商可以把其他開發商預先編寫的軟體組件組合起來，這樣，他們就比以往更多地依賴於為其編寫的軟體API。總而言之，不管我們設計什麼API，最重要的是首先要弄明白我們在為什麼目標或者為誰在設計。這是一定要記得的關鍵點。只有在我們理解目標受眾的需求之後，我們才可能創建有用的API，才能實現恰當的用戶介面，才能讓不同人設計的不同軟體部分良好地集成。 from： http://ke..com/view/1137050.htm

Ⅸ 二次開發介面軟體是啊什麼意思

就是在原有的基礎上提供二次開發的軟體，其埠既是。二次開發，簡單的說就是在現有的軟體上進行定製修改，功能的擴展，然後達到自己想要的功能，一般來說都不會改變原有系統的內核。一般的來說，一些大公司如IBM開發了一個大型的軟體系統平台，根據不同的客戶的需要，一些其它的中小公司為客戶根據需求在該平台上進行第二次有針對性的開發。

Ⅹ 軟體介面

系統採用大量的基於 Windows 平台的軟體平台，系統平台之間有兩種介面方式: 一是緊密結回合，從底層開發相應的介面程答序; 二是數據引擎，僅通過相互調用資料庫的數據引擎進行介面。

由於本系統涉及多種數據需求和功能需求，單純地在一種軟體平台上進行開發不能很好地兼顧其他方面的需求，如採用 ArcGIS 為基礎平台軟體，則該軟體在遙感影像的處理上能力很弱，同樣，選用 ENVI 遙感軟體，則數據後期的分析能力很弱。因此，本系統採用了網路環境下多種軟體平台的集成，充分發揮各個軟體的優勢，並人為地將整個系統分為 4 個相對獨立的子系統，各子系統完成特定的功能; 通過子系統的劃分，消除掉了第一種緊密結合介面方式，而將其他平台與數據平台的結合方式轉變成了數據引擎方式。採用數據引擎方式，很好地體現了系統的功能需求，各子系統模塊間功能明確，各子系統之間只要定義好數據介面，開發人員就可以並行開發，這對於系統後期的升級和維護非常方便。