iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 14
1
Modern Web

Go!從無到打造最佳行動網站系列 第 14

Day14 初次見面 應用程式介面 ApplicationProgrammingInterface (上)

  • 分享至 

  • xImage
  •  

api
(圖片引用from https://www.vectorcast.com/)

今天就迅速簡單的來理解什麼是API (Application Programming Interface)
我認為是程式之間溝通的橋梁。像是在web開發中有分前端、後端、客戶端、伺服器端...等等,在前端開發我們透過javascript來控制頁面上的資料呈現,後端或許使用PHP語言來做商業邏輯的處理,我們通常會將資料放在伺服器端的資料庫,透過後端處理過呈現給前端,今天撇除資料庫與後端得到資料的關係,我們可以透過API讓前端與後端做為溝通的介面,這些動作行為不一定要透過整個頁面的傳送,也可以做溝通。

REST / RESTful

其中最有名在實作API的方式,當然就是REST (REpresentational State Transfer),我們也會聽到設種API設計的方式稱為RESTful,他是一種API的一種風格,因為實在是太多人使用這樣子的風格,所以我們大多在設計API時,也會依循著這樣子的默契來開發,當然這種風格也有一些他的規範與限制在
下面我們將介紹有哪些規範與限制,如果你開發的程式中沒有遵循這樣的模式,那也稱不算是RESTful。

主從式架構 (Client-server Architecture)

我想這應該也不用再多說什麼,大多數的服務並不是點對點式的架構。

無狀態(Statelessness)

你的設計必須是獨立的,像是網站會員登入前與登入後,都與API無關,單純的處理一件事。(這個描述的有點抽像,但意思在於,你不能預設他是有一定的狀態才發生的)

可快取的 (Cacheability)

必須是可以快取的,在你的Server端或Client端必須有。

分層系統 (Layered system)

透過分層式的設計,你可以實作資料的處理,以及其他的應用。

統一介面 (Uniform interface)

e.g. 透過HTTP的METHOD GET來獲取資料,DELETE來刪除資料...等等的行為,已及HTTP Header中Content-Type ...等。

視需求執行的程式碼 (Code on demand (optional))

(翻譯的有點爛xDD)這個選項式可以選擇要不要去實作的,他的意思是在客戶端可以做其他的事情,e.g. 在接收API回應時,可以將javascript的程式碼傳送到Client去執行。這不是RESTful設計中必需的。

針對這個大項目整理一下,其實網路上也有很多類似的文章,不過對我來說可能要自己去動手查一查寫一寫才會真的記在心裡的感覺,以上。


上一篇
Day13 古法私釀、糞扣 Go (BeeGo Framework 練習二)
下一篇
Day15 初次見面 應用程式介面 ApplicationProgrammingInterface (下)
系列文
Go!從無到打造最佳行動網站30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言