關於 API

1.

API（Application Programming Interface,應用程序編程接口）是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內部工做機制的細節。

 

2.

簡單來講就是函數。
好比你寫了一個庫，
裏面有不少函數，
若是別人要使用你這個庫，
可是並不知道每一個函數內部是怎麼實現的。
使用的人也就只是知道這個函數的入口參數和返回值或者這個函數是作什麼的。
對於用戶來講 ，
你的這些函數就是API。
API(Application Programming Interface應用程序編程接口) 是一些預先定義好的函數，
目的是提供應用程序以及開發人員基於某軟件或硬件得以訪問一組例程的能力。

做者：愛要不留餘力
連接：https://www.zhihu.com/question/38594466/answer/147066011
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

 

3.

給你舉個特別容易理解的例子

有一天，輪子哥寫了一個專門抓取知乎小黃文的AI，而他天天都會查閱小黃文列表而且點贊。剛好你也是小黃文愛好者，那麼輪子哥的帳號對你來講就是API接口，你要作的惟一事情就是關注輪子哥帳號，天天只須要查閱輪子哥的動態就能看到小黃文，可是不用關心輪子哥究竟是用什麼方法找到這麼多小黃文的。

做者：彭天浩
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

 

4.

 

通俗的講API 就是先後端間的聯通。假象你去一家餐廳，桌子上有一份菜單，廚房能爲你提供菜單上的菜式。那麼咱們還缺乏一個能和後廚聯繫的人，因此服務員MM就是去告訴後廚你選的菜，再將菜帶回到你的桌子上。MM帶着你的request去告訴system，而後將response 帶回給你。

來看一個API案例，airline system ,你訂機票，你將你的航程提交，會訪問網站的database,來看你選擇的日期，座位是不是可選。但若是你不是在他的網站上訂機票，你是在一個彙總不一樣的航班信息的online travel service 上，那麼這個service 調用了 前面airline system 的API 。這個接口就像上面例子的服務員MM，帶着你的要求去airline system 上 收集信息 ，而後帶回到online travel service 上 。因此你就把它想象成你的服務員MM在先後端間交付數據，建立聯繫。

做者：我要幹掉太陽
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

 

5.

 

做者：優達學城（Udacity）

我最近跟一位 Techstars 的創業家聊天時，問了她一個問題：「大家公司的 API 是什麼？」 這聽起來是個挺奇怪的問題，但其實並非。 

每家創業公司都有一個面向外界接口。有些接口很是簡單，好比說 Google，你只要輸入關鍵詞搜索就好；有些接口複雜一些，好比在 Amazon 上買東西，你能夠瀏覽商品、搜索商品、添加商品到購物車、下訂單、請求退款，等等。

 即便你不是工程師或是產品經理，思考你的公司會向外界提供什麼 API 也是頗有幫助的。這可以使你對本身的業務是什麼以及爲何有更加清晰的認識。

 API 思惟幫助你保持最簡和清晰。

 API 是什麼？

 API（Application Programming Interface）即應用程序接口。你能夠認爲 API 是一個軟件組件或是一個 Web 服務與外界進行的交互的接口。而咱們在這裏要談論的，是做爲一家公司如何跟外界進行交互。從另外一個角度來講，API 是一套協議，規定了咱們與外界的溝通方式：如何發送請求和接收響應。

  

讓咱們拿網站上常見的複選框（checkbox）做爲例子。複選框的接口容許你選擇或者取消選擇它。

 

/check -- causes checkbox to be checked
/uncheck -- causes checkbox to be unchecked

 

再舉個例子，Digital Ocean（VPS 供應商）提供的一次性啓動 10 個服務器的 API 可能長成這樣：

 

/launchServers?numServers=10 -- starts running servers in the cloud.

 

在這個例子中，launchServers 命令容許用戶指定要啓動的服務器的數量。絕大多數服務都支持這樣的自定參數，一是更靈活，二是複用性好。要是啓動 10 個服務器和 20 個服務器有兩個不一樣的命令，那就太蠢了，由於它們本質上是同樣的。

 

商業API 又是什麼？

 

設計你的商業 API 時，能夠從你的業務有哪些關鍵概念入手來考慮相關的命令，這樣會比較方便。思考：你的用戶們能夠作哪些事情？下面是一些簡單的例子：

 

http://google.com/search?term=techstars

http://amazon.com/browse?category=books

http://amazon.com/buy?bookId=b&customerId=c

http://uber.com/orderCar?location=loc&customerId=c

http://twitter.com/postTweet?text=t&userId=u

http://facebook.com/friend?userId=u&friendId=f

 

如今的服務大多都運行在雲上，經過 HTTP 協議與外界交互。這不是太直觀，由於咱們和用戶看到的都是界面美觀友好的 APP。但實際經過 HTTP 傳輸的是這些命令。它們很是重要，由於這些最底層和直接的接口最終決定了你的用戶可以如何使用你的服務。經過這樣的思考，咱們才能透過人機界面理清業務的核心。

 

如何設計你的商業API？

 

如今讓咱們把注意力集中到你的公司。開始創業時，你有一大堆事情要作：尋找和理解創始人與市場之間的契合，跟用戶溝通，思考大家獨有的看法和優點，市場策略，等等等等。除此之外，設計商業 API 也是你在早期就應該作的事情之一。

 

花點時間研究 HTTP 協議吧（真的不難）！在開發你的 MVP（Minimum Viable Product，最簡可行產品）以前，你就要把 API 設計好了。

 

設計 API 能夠幫助你理清本身的業務。你會在這個過程當中決定 MVP 中會包含哪些東西，不包含哪些東西。你會給某些命令更高的優先級。最後，拿一張紙把設計好的 API 寫下來，你就知道本身是提供了太多仍是太少。

 

儘量地將你的 API 設計得簡單和優雅。不要考慮應該添加什麼，而是想一想應該去掉什麼。

 

有了基礎的 API 之後，跟客戶和團隊溝通起來就方便多了。這將爲你接下來打造 MVP 提供堅實的基礎。

 

當你設計出使人滿意的 API 以後，就去實現它吧。一個一個讓原始 API 能經過 HTTP 被訪問。沒錯，你如今還不須要花哨的界面。在實現的過程當中，你會對本身的業務有更深的瞭解。

 

隨着業務增加，升級你的 API

 

隨着你的業務進化和增加，你的 API 也須要做出改變。持續地更新和改善它。能夠擴充它，但要 「矜持」 一點。最偉大的公司都有着簡單的 API。

 

想一下 Google，它提供了一個很是簡單的接口，但內部的工做原理是無比複雜的。相似地，喬布斯老是驅動 Apple 公司來不斷簡化用戶界面。Apple 的產品每每經過簡單的界面來隱藏背後的工程複雜度和首創性。

 

「你會但願你的業務越簡單越好，隱藏在接口背後的服務越有價值越好。」

 

在業務增加的過程當中，一些子業務可能會演化出它們本身的 API。你可能會有公共接口和內部接口。這時將接口保持得簡單而整潔就開始凸顯價值了。不斷鞭策本身去實現和使用簡單的接口。

 

「你的業務自己永遠是你的 API 的第一個也是最大的用戶。」

 

一般伴隨着業務增加，用戶訪問你的服務的方式也會愈來愈多。你可能同時有桌面版應用和移動端應用，短消息服務，機器人，iOS 和 安卓應用，等等。這些都是你的 API 的用戶，也是你的業務的用戶。

 

咱們生活在一個雲服務和自動化的時代。每家互聯網巨頭，Google、Amazon、Facebook 等，都爲他們的服務提供了 API。而在將來，全部的服務都將在一個圖形界面之外擁有編程接口。隨着人工智能和自動化逐漸進入咱們的世界，愈來愈多的請求和訪問會在這些雲服務和 API 之間發生。若是你打算創業，爲了準備如此激動人心的將來，你能夠從思考和實現本身的 API 作起。

 

本文由優達學城（Udacity）編譯，翻譯：章凌豪，原文參考自 http://alexiskold.net。