後端框架與API 開發(6-1) - Web API

閱讀時間約 4 分鐘

※ 什麼是Web API

API 就是後端開出來讓前端來用的介面,讓前端與後端可以溝通。

API流程:

  • 終端使用者用任何一種裝置進入瀏覽器。
  • 瀏覽器透過 API 向後端發出請求,請求查詢或修改資料。
  • 後端透過 API 收到前端的請求後,取得資料並回應給前端。
  • 前端渲染畫面,終端使用者看到頁面。


raw-image


※ API 溝通文件:

API 文件的主要目標是使開發人員能夠有效地使用 API,並為他們提供必要的訊息,以實現應用程序的相互操作性和功能。

 API 文件可能包含的內容如下:

  1. API 描述:對API的簡要概述,包括其功能、用途和重要性。
  2. 路由和請求:詳細描述 API 的各個路由以及可用的HTTP請求方法(如GET、POST、PUT、DELETE等)。這部分通常會包括路由的 URL 和所需的請求參數。
  3. 參數:對請求參數的描述,包括每個參數的名稱、類型、是否必填以及範例。
  4. 回應:對 API 回應的描述,包括成功回應的格式和可能的錯誤回應。這通常包括 HTTP 狀態碼和相關的錯誤消息。
  5. 身份驗證和授權:如果API需要身份驗證或授權,則文件通常會提供相關信息,例如需要 API 金鑰、token 或 OAuth 流程。
  6. 版本控制:如果 API 具有多個版本,則文件通常會指示如何指定所需的 API 版本。

※ API 溝通文件的範例,「登入功能」:

raw-image

這條規格講定了後端的輸出格式,以及前端必須傳入的參數。在講定文件之後,後端去開發 API 伺服器,按規格回傳資料,而前端則可以根據文件裡定義的 JSON 格式,自行模擬資料來開發畫面。

※ API 溝通文件常見格式:JSON

  • JSON: JavaScript Object Notation 的縮寫,它參考了 JavaScript 中物件結構的表示方式。
  • JSON的優點較為輕量、易於閱讀,幾乎所有網頁開發相關的語言都有解析 JSON 資料的函式庫。
  • JSON 的語法建立在 JavaScript 對於 Array 和 Object 的表示方式,資料結構中通常也會運用 array 和 object 的嵌套關係,例如:
  1. 外層是 array,裡頭包含其他 object
  2. 外層是 object,裡頭還有其他 object
  • JSON 還可以處理字串 (String)、數字、布林值 (Booleans) 以及空值 (null)。

※ 什麼是「後端負責回傳資料」?

前後分離的分工模式,主要差異在於,回傳 JSON v.s. 回傳 view template。後端的主要工作就是處理請求並回傳資料,而這些資料通常是以 JSON 格式回傳的。這種方式讓前端可以專注於處理使用者介面和使用者體驗,而後端則專注於資料處理和商業邏輯。這種分工模式提高了開發效率並使應用程式更易於維護。

※ 設計 Web API 

API 的設計中一般來說可以分為兩種切入點:使用者角度,以及需求角度。兩種角度在業界都很常被使用、有各自的優劣勢。

  • 從需求角度看 API:等同於從單一頁面來思考,比較像 MVC 開發所做的事情。

以下圖為例,當我們想取得某個頁面,會透過一支 API 直接取得所有頁面資料;同理,在另一個頁面,也有一支 API 取得所有資料。

這種設計方式隱含的意義,就是將資料組裝的任務交給後端工程師。前端工程師會開出頁面的資料需求,後端依照需求回傳資料,填充畫面上需要的資料。

raw-image
  • 從使用角度看 API:後端工程師會將現有的資料開成 API 選項,前端需要使用時就自己拼湊。

這種設計方式隱含的意義,是將組裝資料的責任放到前端身上。一開始後端工程師會從資料庫確定現有的資料,再針對資料作出增刪改查的 API,前端再拿這些 API 拼湊出頁面。

以下圖為例:

  1. 一個元件取一支 API,如元件 1 對應一支 API。
  2. 也可能一個元件取多支 API,像元件 2 需要拿兩支 API 資料。
  3. 有些元件會重複出現,像元件 2 在頁面 1、頁面 2、頁面 3 皆有出現,即會重複使用 API 3 與 API 4。
raw-image

※ RESTful 風格

先提供 API 再組裝,API 設計就會跟 RESTful 風格很有關。API 的設計中命名是很關鍵的事。好的命名會讓你的 API 更易於上手與使用,而 RESTful 風格的好處就在具備非常高的可讀性,例如,我們看到 get 就知道這支 API 要拿資料,不需要看文件。

raw-image


    全端網頁開發專業知識分享
    留言0
    查看全部
    avatar-img
    發表第一個留言支持創作者!
    ※ 原本狀態:伺服器渲染 這是 MVC 架構下的 request / response 示意圖,在這張圖呈現的架構裡,畫面和資料都由同一個架構處理。 伺服器渲染流程: 瀏覽器針對特定網址送出請求。 路由器解析請求後,轉接給對應的 controller。 controller 按照要求,透過
    ※ 什麼是Middleware (中介層)? Middleware 一般翻譯作「中間件」或是「中介軟體」,其實 Express 應用程式就是由一連串的 middleware 串連而成: 從 request 進來到 response 回去會經過一系列的流程。 這個流程會按照路由清單由上而下執行。
    ※ Params是什麼? 在網頁開發中,params代表的是參數(Parameters)。當你在路由(Route)中定義了一個或多個變數時,這些變數的值就會被存儲在 params 對象中。所以,params 就是用來存儲路由參數的地方,這些參數可以在處理請求時使用。 ※ Params的兩個功能:
    ※ 什麼是路由? 當我們說「路由」時,可能是在談論路由器(實體設備),也可能是在談論路由(選擇路徑的過程),或者是在談論路徑(資料封包的傳輸路徑)。 路由器 (Router):這是一種實體設備,負責將資料封包 (Packet) 從一個網路傳送到另一個網路。它的工作方式類似於交通指揮,確保資料封包
    ※ 什麼是 Helper? Helper 通常指的是樣板引擎裡的邏輯工具。當我們想做的事情超越內建功能時,就可以自訂 helper。 ※ Handlebar helper的用處 說明:Handlebars helper 是一種自定義函數,可以在 Handlebars 模板中執行邏輯操作。這些函
    ※ 用 faker 套件產生假資料步驟 安裝 faker套件:快速生成假資料(人名、地名、時間)。 npm install faker@5.5.3 引入 faker 套件: const faker = require('faker') 建立data資料夾來生成假資料。創建一個名為 gene
    ※ 原本狀態:伺服器渲染 這是 MVC 架構下的 request / response 示意圖,在這張圖呈現的架構裡,畫面和資料都由同一個架構處理。 伺服器渲染流程: 瀏覽器針對特定網址送出請求。 路由器解析請求後,轉接給對應的 controller。 controller 按照要求,透過
    ※ 什麼是Middleware (中介層)? Middleware 一般翻譯作「中間件」或是「中介軟體」,其實 Express 應用程式就是由一連串的 middleware 串連而成: 從 request 進來到 response 回去會經過一系列的流程。 這個流程會按照路由清單由上而下執行。
    ※ Params是什麼? 在網頁開發中,params代表的是參數(Parameters)。當你在路由(Route)中定義了一個或多個變數時,這些變數的值就會被存儲在 params 對象中。所以,params 就是用來存儲路由參數的地方,這些參數可以在處理請求時使用。 ※ Params的兩個功能:
    ※ 什麼是路由? 當我們說「路由」時,可能是在談論路由器(實體設備),也可能是在談論路由(選擇路徑的過程),或者是在談論路徑(資料封包的傳輸路徑)。 路由器 (Router):這是一種實體設備,負責將資料封包 (Packet) 從一個網路傳送到另一個網路。它的工作方式類似於交通指揮,確保資料封包
    ※ 什麼是 Helper? Helper 通常指的是樣板引擎裡的邏輯工具。當我們想做的事情超越內建功能時,就可以自訂 helper。 ※ Handlebar helper的用處 說明:Handlebars helper 是一種自定義函數,可以在 Handlebars 模板中執行邏輯操作。這些函
    ※ 用 faker 套件產生假資料步驟 安裝 faker套件:快速生成假資料(人名、地名、時間)。 npm install faker@5.5.3 引入 faker 套件: const faker = require('faker') 建立data資料夾來生成假資料。創建一個名為 gene
    你可能也想看
    Google News 追蹤
    Thumbnail
    嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
    Thumbnail
    需求情境: 在設計畫面時,資料來源是後台的 api,每一次畫面細節的修修改改,都會觸發 Xcode Preview 程序,導致不斷呼叫後台。此時若資料結構和大小都具有一定規模,就會導致效率低落,不斷等待,且消耗伺服器資源甚鉅。 解決方案: 將後台傳回的資料以檔案形式暫存在本地端,每次 pr
    xhr 在下面的例子裡,我們首先建立了一個 XMLHttpRequest 物件,並使用 .open() 開啟一個 URL,最後使用 .send() 發出 request。 具體來說步驟有四個: 建立XMLHttpReque 開啟一個請求。 送出請求。 拿到回應後去處理畫面要如何呈現。
    Thumbnail
    透過零售業的數位轉型,消費者期待獲得更多元的服務體驗。API 技術在電商、庫存管理和訂單處理等方面發揮關鍵作用,幫助企業提升效率並擴大營運範圍。API 管理平台為企業帶來高彈性、安全的 API 策略,加速數位轉型,提高企業韌性。昕力資訊的 API 管理平台為企業提供強力支持,助力產業進步。
    Thumbnail
    當我們在撰寫一套系統的時候, 總是會提供一個介面讓使用者來觸發功能模組並回傳使用者所需的請求, 而傳統的安裝包模式總是太侷限, 需要個別主機獨立安裝, 相當繁瑣, 但隨著時代的演進與互聯網的崛起, 大部分的工作都可以藉由網頁端、裝置端來觸發, 而伺服端則是負責接收指令、運算與回傳結果, 雲端
    Thumbnail
    在開發前後端分離架構時,使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大,揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢,但application/json會觸發預檢請求,需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
    Thumbnail
    當這產品的這個 API 被呼叫,再從回傳內容的某個欄位欄位來判斷,只要“這個欄位”顯示 false 就代表不支援」,雖然這樣的設計也能滿足功能需求…
    Thumbnail
    JavaScript 套件,頁碼 Pagination.js 搭配 axios API 請求範例
    Thumbnail
    先前幾篇筆記介紹了網路請求,瀏覽器儲存資料的方式,那麼實務上,前端最常需要發送網路請求的時候,就是透過呼叫 API,去向後端工程師發送/請求資料,所以今天來記錄什麼是 API吧!
    Thumbnail
    Request內容 package main import ( "fmt" "log" "net/http" "strings" ) func request(w http.ResponseWriter, r *http.Request) { //這些資訊是輸出到伺服器端的列印訊息
    Thumbnail
    Accept:用戶端能夠接收的內容類型。 Accept: text/plain, text/html Accept-Charset:瀏覽器可以接受的字元編碼集。 Accept-Charset: utf8 Accept-Encoding:指定瀏覽器可以支援的web伺服器返回內容壓縮編碼
    Thumbnail
    嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
    Thumbnail
    需求情境: 在設計畫面時,資料來源是後台的 api,每一次畫面細節的修修改改,都會觸發 Xcode Preview 程序,導致不斷呼叫後台。此時若資料結構和大小都具有一定規模,就會導致效率低落,不斷等待,且消耗伺服器資源甚鉅。 解決方案: 將後台傳回的資料以檔案形式暫存在本地端,每次 pr
    xhr 在下面的例子裡,我們首先建立了一個 XMLHttpRequest 物件,並使用 .open() 開啟一個 URL,最後使用 .send() 發出 request。 具體來說步驟有四個: 建立XMLHttpReque 開啟一個請求。 送出請求。 拿到回應後去處理畫面要如何呈現。
    Thumbnail
    透過零售業的數位轉型,消費者期待獲得更多元的服務體驗。API 技術在電商、庫存管理和訂單處理等方面發揮關鍵作用,幫助企業提升效率並擴大營運範圍。API 管理平台為企業帶來高彈性、安全的 API 策略,加速數位轉型,提高企業韌性。昕力資訊的 API 管理平台為企業提供強力支持,助力產業進步。
    Thumbnail
    當我們在撰寫一套系統的時候, 總是會提供一個介面讓使用者來觸發功能模組並回傳使用者所需的請求, 而傳統的安裝包模式總是太侷限, 需要個別主機獨立安裝, 相當繁瑣, 但隨著時代的演進與互聯網的崛起, 大部分的工作都可以藉由網頁端、裝置端來觸發, 而伺服端則是負責接收指令、運算與回傳結果, 雲端
    Thumbnail
    在開發前後端分離架構時,使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大,揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢,但application/json會觸發預檢請求,需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
    Thumbnail
    當這產品的這個 API 被呼叫,再從回傳內容的某個欄位欄位來判斷,只要“這個欄位”顯示 false 就代表不支援」,雖然這樣的設計也能滿足功能需求…
    Thumbnail
    JavaScript 套件,頁碼 Pagination.js 搭配 axios API 請求範例
    Thumbnail
    先前幾篇筆記介紹了網路請求,瀏覽器儲存資料的方式,那麼實務上,前端最常需要發送網路請求的時候,就是透過呼叫 API,去向後端工程師發送/請求資料,所以今天來記錄什麼是 API吧!
    Thumbnail
    Request內容 package main import ( "fmt" "log" "net/http" "strings" ) func request(w http.ResponseWriter, r *http.Request) { //這些資訊是輸出到伺服器端的列印訊息
    Thumbnail
    Accept:用戶端能夠接收的內容類型。 Accept: text/plain, text/html Accept-Charset:瀏覽器可以接受的字元編碼集。 Accept-Charset: utf8 Accept-Encoding:指定瀏覽器可以支援的web伺服器返回內容壓縮編碼