API

API 的全名是 Application Programming Interface，維基百科上的中文譯名是「應用程式介面」，而這個 API 所指的是一個中間的介面。你可以透過他與軟體互動、取得服務、資料等等。

像是在看電視的時候，是透過遙控器來轉台、調整音量、開關電視、切換 DVD 播放還是接收數位、類比電視訊號，而這時候在你與電視之間的溝通橋樑、在你們之間的 API，就是遙控器了。

• 使用者：我
• API：遙控器
• 伺服器、資料來源：電視機

現在在速食店點餐的時候除了排隊跟店員直接點餐之外，不少店家的門口附近多了三四台的點餐機可以讓你直接點餐，這個情境之下，你與速食店的餐點是透過這個點餐機來連起來的，說這個點餐機是你用來從速食店取得餐點的 API 也不為過。

• 使用者：顧客
• API：點餐機
• 伺服器、資料來源：速食店

以上的兩個例子我們可以換個角度來看，對你（使用者、顧客）來說，只需要知道遙控器、點餐機的操作方式就可以了，不用去知道電視的音量大小、頻道切換、速食店的餐點製作、薯條不加鹽人家就要整個重炸...等等這些事情。

換回我們程式開發的角度來看的話就是，我們可以透過 API 來發送我們的請求到伺服器去取得資料，而這過程中我們不用去知道伺服器是如何把我們要的資料整理出來的，我們要做的事是發出符合 API 格式的請求，好讓我們能從伺服器準確地取得所需要的資料。

RESTful API

從上面的敘述可以得知 API 在資料的 Request 與 Response 扮演著什麼樣的角色，當我們要取資料的時候是向伺服器發送符合 API 格式的請求，而其中的符合 API 格式是什麼呢？

REST：Resource Representational State Transfer

• Resource：資源
• Representational：表現的形式、表象（JSON、XML...）
• State Transfer：狀態變化或轉移（HTTP methods）

舉例來說可能有個訂單的 API 設計是：

• GET 取得全部的訂單：/getAllOrders
• GET 取得特定的訂單：/getOrder/5
• POST 新增訂單：/createOrder
• PUT 編輯特定的訂單：/editOrder/3
• DELETE 刪除特定的訂單：/deleteOrder/7

然而不同的專案、工程師、公司所偏好的 API 風格可能會有所不同，在使用的時候勢必得依靠文件的閱讀、對 API 的理解，才能正確地選用合適的 API 來取得資料。

而如果這個 API 的規劃是 RESTful 風格的話：

• GET 取得全部的訂單：/orders
• GET 取得特定的訂單：/order/5
• POST 新增訂單：/order
• PUT 編輯特定的訂單：/order/3
• DELETE 刪除特定的訂單：/order/7

這樣的話就可以有簡潔的 API 格式以及更加符合 HTTP methods 描述的操作行為。

然而實際的開發情境下不太可能每一個 API 都能用這種方式來達到需求，這並不是一個規範、標準，只是一種推薦的 API 設計風格，能將 API 的設計變得較為簡潔。

參考

淺談 API 與 RESTful API - isRayNotArray
什麼是REST? 認識 RESTful API 路由語義化設計風格
API 是什麼? RESTful API 又是什麼?
What is a REST API?
[不是工程師] 休息(REST)式架構? 寧靜式(RESTful)的Web API是現在的潮流？