# RESTful API --- 必須要先有幾個**基本知識** 1. 什麼是HTTP? 2. 簡短的網頁發展史 3. 什麼是API 4. SOAP API 最後才會說到RESTful API --- # 什麼是HTTP? ---- HTTP是一種傳輸協定 Hypertext Transfer Protocol （超文本傳輸協定） ---- ## 簡單來說 ---- 1. 在網路世界中分為客戶端以及伺服端 2. 客戶端向伺服端發送請求(request)來請求資源(resource) 3. 伺服端接受伺服端的請求(request)並根據request回應(response)資源(resource) ---- 而為了統一request和response規範才有了HTTP ---- ## 這樣說可能有點難懂 ----  ---- ## 舉例來說 ---- 假設我要吃滷味 ---- 1. 在瀏覽器中輸入某伺服器網址，按下enter，送出request(跟老闆說我要切兩塊百頁豆腐) 2. 伺服器收到request檢查網址是否存在(老闆聽到我的 ==請求(request)== ，並轉身 ==確認(check)== 是否還有百頁豆腐) 3. 伺服器發送response回來(老闆切好了百頁豆腐送到我手中) ---- 而在上面例子中 ---- 我跟老闆點餐的方式有一定規範 在台灣我必須說用中文，而不是用英文去點餐 大家都有一定的規範就是一種協定(Protocol) ---- 而HTTP就是大家說好在網頁傳輸方面規範 ---- 如果網址不存在伺服器就會回傳網址狀態碼 (HTTP status code) 404:Page Not Found  ---- 而狀態碼又分為幾種 ---- 2xx = Success (成功) 3xx = Redirect (重新導向) 4xx = User error (使用者錯誤) 5xx = Server error (伺服器錯誤) ---- # 常見的狀態碼 ---- ## 200:OK，很棒 表示執行結果沒有問題 ---- ## 301:資源已被永久更換 通常會傳送HTTP Location來重新導向，客戶端轉向更換位置伺服器做Request ---- ## 302:資源被暫時移到新的位置 也會被重新導向，不過與301不同的方在於客戶端應當像原本的伺服器發送Request ---- ## 304:不須更動 東西跟之前長一樣去你自己電腦的快取(Cache)拿就好 ---- ## 401:尚未認證可能需要登入或Token ## 403:沒有權限 ---- ## 500:伺服端錯誤 ## 502:通常是伺服器的某個服務沒有正確執行 ---- 在HTTP中會有很多request method ---- 1. GET 2. HEAD 3. POST 4. PUT 5. DELETE 6. CONNECT 7. OPTIONS 8. TRACE 9. PATCH --- # 簡短的網頁發展史 ---- ## 網頁發展初期 ---- 那個時候主要是**靜態網頁** (只有提供HTML文本)  ---- 對於早期的網頁可以說是一本書 ---- 可以說是比收音機還無聊 ---- 不過時代是會進步的 ---- 那時候出現了**CGI** ---- ## CGI? ---- Common Gateway Interface ---- # 舉例來說 ---- 假設今天有一本電子日記本 ---- 如果你今天寫日記後來想要修改日記內容，應該不會去==更改HTML== 而是將==內容放到資料庫==中，日後在做修改的時候，從資料庫去修改 這樣一來伺服器==每天就會讀到不同的內容== ---- 而==資料庫與伺服器==之間的==溝通介面==就叫做**CGI** ---- ## 腳本(Script)語言的興起 ---- 那時可以動態顯示網頁，可是效率並不是很好 ---- 因為CGI對於每個請求都要開一個進程(Process) ---- 於是有了**JSP、ASP、PHP等的腳本語言** ---- 而為了==維持高維護性==，有一個好的方法就是將HTML做成模板，然後依照這個模板去填入資料 ---- ## 前端工程師的工具CSS ---- 為了讓網頁漂亮 ---- **CSS(Cascading Style Sheets)** 誕生了 CSS1在1991年被提出，涵蓋了一些簡單且基本的功能例如行距、字的顏色、大小等等... ---- ## MVC 架構 ---- Model-View-Controller一種軟體架構模式 最早由Trygve Reenskaug在1978年提出 ---- 目的是實現一種==動態的程式設計==模式 使後續的==程式修改、擴充==更加**簡化** **降低**系統複雜度，使系統更好**維護與擴充**。 ---- 而MVC有三個基本元件 ---- # Model 負責資料和邏輯 ---- # View 負責畫面顯示 ---- # Controller 負責接收請求，協調Model與View回應結果。 ---- ## MVC架構的經典圖  ---- ## 網頁設計方面 ---- ### MVC架構圖可能長成這樣  ---- ### MVC架構套用在網頁設計能解決什麼樣的問題? ---- 使用MVC架構可以更能區分「邏輯處理」與「資料呈現」 明確的區分各元件的功能，提高系統擴充性、可用性 ---- 而且 導入MVC架構更可以進行分工，團隊每個人可以負責自己的部分進行開發，不互相干擾 ---- ## MVC用於網頁設計的優點 擴充性高 方便管理 使程式結構更加直覺 有利於團隊分工 ---- ## MVC有什麼缺點? 需要嚴謹的系統規劃、開發時間可能會拉長 系統結構複雜，不適合小型專案 系統龐大，效能降低 --- # 什麼是 API? ---- Application Programming Interface 在各種軟體組件中，所定義的==一組協議==用在不同軟體中做==資料傳輸== ---- 好的API 提供 model 並由工程師組合在一起，讓程式可以容易撰寫。 API的使用者是正在開發軟體的軟體工程師 ---- ## 例如 ---- Socket介面是TCP/IP的API 裡面定義了許多函式或例程，用來開發TCP/IP在網路上的應用程式 ---- ## 還是有點太複雜 ---- ## 舉例來說 ---- 假設你想喝一杯飲料，你手上有一個==菜單== ---- 如果你跟店員點==沒有在菜單上面的飲料== 店員會跟你說，沒有這個飲料(404) ---- 那如果你點了一杯飲料 你會拿到一杯你想喝的飲料 ---- 在這個情境中 ---- 你依照菜單上面==所擁有的格式填寫== 你==不需要知道==你點的那杯飲料==是怎麼做的== 但是你還是可以很開心地去享受這杯飲料 ---- 而API的概念就很像上述所說的例子 ---- ## 另一個例子 ---- ## 在訂票機的系統中 ---- 你填完自己資料，並送出 票就如同魔法一般，從訂票機中吐出來 ---- 所以當你點擊確認鍵的時候 你所用的瀏覽器就會把你的資訊 ---- **透過API**送到伺服器中 而伺服器就會==解析並處理你的資訊== 在將結果**透過API**在送到你面前 ---- 在過程期間你可能沒有感受到 應用程式之間的交替以及溝通 ---- ## 進一步說 ---- 開發者在開發網頁的時候 **不見得必須**知道信用卡資訊==是怎麼被認證==的 開發者只要知道==要怎麼信用卡資訊送到另一端== 讓資訊被驗證就可以了 ---- 而API的好處就在這邊 ---- 可以讓開發者**節省**很多時間 也不需要去寫多餘的Code 讓整個程式平台之間達到==一致性== ---- ## API可以控制資源被誰或是怎麼被使用的(取得驗證的角色) ---- ## API用於服務之間的溝通 ---- ## 聽到這裡 ---- ## 你會發現API這個詞 ---- ## 就是一個定義非常廣的字 ---- # API分類 ---- ## 依照API的公開性分成三種 ---- # Open API 又叫做Public API，免費可以供任何人使用 如:FacebookAPI、GoogleMapAPI ---- # Partner API 只給有使用權的開發者使用 如:The Ticketmaster PartnerAPI(買票系統) ---- # Internal API 給內部系統做使用的，完全不對外開放 ---- ## 依照Protocol、Architecture去分類 ---- 1. Local APIs 2. Web APIs 3. Program APIs ---- # Web API ---- 在 Web Application 的開發情境下的 API 被稱為 Web API ---- Web API 是一個系統或者是軟體 透過Addres 例如URL 來提供服務或者是提供Access ---- 在 Web API 作用時，客戶端和伺服器端會透過 HTTP 通訊協定來進行請求與回應。 ---- ## Web API 是一種接收請求以及發送回復的媒介 ---- 在客戶端(瀏覽器或手機等)發送請求告訴伺服端你想要什麼，而伺服器透過你的請求回傳一個相對應的資源給你 ---- 所以當A伺服器有Web API介面時，不同伺服器可以透過不同的需求跟A伺服器的Web API介面拿取不同伺服器所需要的資源 ---- ## 開發者方面 ----  ---- ## 舉個例子 ---- 假設你是開發餐廳網頁的工程師，你需要把你的餐廳網頁放入Google Map地圖資料 你會經歷以下步驟 ---- 1. 登入Google Map API 網站**找尋**你要使用的Web API 2. 閱讀Google Map API 所提供的==Document== ，了解==怎麼使用Google Map API== 3. **註冊** Google Maps API 帳號，並且取得金鑰 (Key) 通過==驗證== 4. 取得金鑰 (Key) 後，就可以將 Google Maps API 提供的 API 放進自己的專案，API 的呈現會是一組程式碼，你需要自行改寫其中的 Key 和地址 5. 完成程式碼改寫之後，就可以在網頁中讀取 Google Maps 的地圖了 ---- ## Web API主要可以分成4種 1. REST 2. JSON-RPC 3. XML-RPC 4. SOAP --- # SOAP API ---- Simple Object Access Protocol(簡單物件存取協定) 它就是一個Protocol ---- SOAP指的是一種提供給Web Services以XML製作出來的通訊協定 有了SOAP的規範，資源就可以在不同伺服器中做傳遞 ---- ==不需要知道==彼此伺服器的邏輯細節是什麼 而基於XML協定它共分了**四個部分** ---- ## SOAP Envelop 定義一個描述訊息是什麼、被誰傳送的、誰應該接收並處理以及如何處理它 ---- ## SOAP encoding rules 定義了一種序列化的機制，用於表示應用程式需要使用的資料類型的實例 ---- ## SOAP RPC representation 定義了一個協定，用於表示遠程過程調用和應答 ---- ## SOAP Binding 定義了SOAP使用哪種協議交換資訊。使用HTTP/TCP/UDP協議都可以 ---- ## SOAP的傳輸方式 可以使用HTTP或SMTP的協定拿來做訊息傳遞，但是HTTP在現今的網際網路中都可以工作得很好，所以被廣泛採納，SOAP也可以用在HTTP**S** ---- ## SOAP Request  ---- ## SOAP Response  --- # RESTful API ---- ## REST的設計者  ---- ## Roy Thomas Fielding 他是HTTP協議（1.0版和1.1版）的主要設計者 Apache伺服器軟體的作者之一 Apache基金會的第一任主席 **REST**這個詞是他在2000年的博士論文中提出的。 ---- ## REST **Re**presentational **S**tate **T**ransfer (表現層狀態轉移) ---- REST是一種設計風格 ---- 而RESTful只是轉為形容詞，**RESTful**代表用==REST設計風格==所設計出來的API，稱為RESTful API ---- ## RESTful API ---- ## 舉例來說 ---- 當你在餐廳中 ---- 如果你使用**一般的API**點菜，可以加點、查看已點菜色、修改已點菜色、取消已點菜色 都會需要==不同的服務生==替你服務 ---- 而如果你使用**REST設計風格下的API**點菜，就是讓剛剛說的所有動作變成==同一個服務生==替你服務 ---- 而 RESTful API 主要由三個元件組成  ---- # Nouns名詞 定義資源的位置，在網路上每個資源都有一個獨一無二的位置 ---- # Verbs動詞 對資源所要做的動作 ---- # Content Types # 資源呈現方式 讓API可以以多種方式表現，其中最常用的為JSON格式，較輕也較好處理 ---- 在==一般API==中他的資源位置表示方式可能為 ``` 獲得資料GET /getData 新增資料POST /createData 刪除資料DELETE /deleteData/1 ``` ---- 這種方法 不同公司不一樣的工程師，設計名稱都會不一樣，==沒有統一的命名方式== ---- 若你==RESTful的設計風格來設計== API的話資源位置表示方式就會是 ``` 獲得資料GET /data 新增資料POST /data 刪除資料DELETE /data/1 ``` ---- 用一個唯一的URL定位資源，將動作藏在HTTP Method中 ---- ## 使用RESTful風格設計出來的API就會有幾個優點及限制 ---- ## 有唯一的URL表示資源位置，統一的API介面(Uniforn Interface) ---- # 無狀態性(Stateless) ---- 這邊所謂的==狀態==是指==HTTP請求狀態== ---- 在Client跟Server交互資訊時，Server透過Session保存Client的請求狀態 同一個Client在下一次請求的時候，透過保存在Server的Session來Request ---- 而無狀態意思是==Client端自行保存狀態== 請求時一併附上給Server Server端不保存Client的狀態資訊 ---- # 可更高效的利用快取來提高回應速度(Cachable) ---- ## 簡單來說 ---- 在Server端 GET過的資源，如果沒有被變更過 可以利用==Cache機制減少Request== ---- 在Client端 client端透過Cache**紀錄**Cache版本 若向==Server的最新版與Cache版本==相同 Client端直接取用自己的資源即可 (HTTP Status code 304) ---- # 分層系統架構(Layered System) ---- # 客戶端與伺服端分離(Client-Server) ---- ## 充分利用HTTP Method (GET/POST/PUT/DELETE) ---- ## 可執行程式碼的設計，像JavaScript Code-On-Demand(Optional) ---- ## REST 優於 SOAP的地方 REST 提供多元的資料格式如JSON、XML等 而SOAP 只有XML一種 基於JSON ，REST被公認是==易於處理的== 基於JSON ，REST提供==瀏覽器更好的支援== 在==快取方面== REST 有著優越的性能 世界級大公司主要服務協定 REST一般而言**比較快且也較省頻寬** --- # 參考 ---- https://medium.com/itsems-frontend/api-%E6%98%AF%E4%BB%80%E9%BA%BC-restful-api-%E5%8F%88%E6%98%AF%E4%BB%80%E9%BA%BC-a001a85ab638 ---- https://blog.kkbruce.net/2018/04/soap-with-rest-good-parts.html#.XwZ3gCj7SUl ---- https://medium.com/@dilankam/restful-api-design-best-practices-principles-ded471f573f3 ---- https://dzone.com/articles/differences-in-performance-apis-amp-more ---- https://zh.wikipedia.org/wiki/%E7%AE%80%E5%8D%95%E5%AF%B9%E8%B1%A1%E8%AE%BF%E9%97%AE%E5%8D%8F%E8%AE%AE ---- https://zh.wikipedia.org/wiki/MVC#/media/File:MVC-Process.svg ---- https://noootown.wordpress.com/2016/04/08/web-development-history-1/ ---- https://www.ibest.tw/mvc-website.php ---- https://zh.wikipedia.org/wiki/MVC#/media/File:ModelViewControllerDiagramZh.png ---- https://www.youtube.com/watch?v=ItWknQTTEx4 ---- https://restfulapi.net/introduction-to-json/ ---- https://unwire.hk/wp-content/uploads/2012/08/www.png ---- http://www.thewebpractice.com/w3c/Style/Examples/011/firstcss-tr.html --- ## Thanks for listening!!