114 年 國立臺北大學資訊管理學系碩士班《計算機概論》

核心觀念：ASCII 編碼、進位轉換。

解題步驟：

1. 理解 ASCII 編碼與字母對應： 題目提到字母 G 的 ASCII 16 進位編碼是 47。我們需要知道 G 在 ASCII 中的值。

   • ASCII 中，大寫字母 A 是 65 (十進位)，B 是 66，以此類推。
   • G 是第 7 個大寫字母 (A=1, B=2, ..., G=7)。
   • 所以 G 的 ASCII 十進位值是 $65 + (7-1) = 65 + 6 = 71$。
   • 題目給的 16 進位 47，轉換成十進位：$4 \times 16^1 + 7 \times 16^0 = 64 + 7 = 71$。這與我們計算的 ASCII 值相符，確認題目給的資訊正確。

2. 理解編碼規則： 題目說「按鍵字母為依序加 1 來編碼」。這表示如果 G 的編碼是 47，那麼 H 的編碼就是 $47+1=48$，I 的編碼是 $48+1=49$，以此類推。

3. 計算 M 的編碼： 我們需要從 G 到 M 總共加多少。

   • 字母順序：G, H, I, J, K, L, M。
   • 從 G 到 M，經過了 H, I, J, K, L，總共是 5 個字母。
   • 所以 M 的編碼會比 G 的編碼多 6 (從 G 到 H 加 1，到 I 加 2，...，到 M 加 6)。
   • M 的 ASCII 十進位值 = G 的 ASCII 十進位值 + 6 = $71 + 6 = 77$。

核心觀念：計算機儲存單位與進位轉換、科學記號。

解題步驟：
題目給了幾個單位的換算關係，以及 G 級的算力，要求 1 EB 相當於 $10$ 的幾次方。這裡的 EB 應該是指 Exabyte (艾位元組)，是一個儲存單位，而不是算力單位。題目中的 P hash/sec, T hash/sec, G hash/sec 都是算力單位，而 EB 則是儲存單位，這是一個可能的陷阱，但我們可以從題目給的關係推導出位元組的數量級。

1. 理解單位換算：

   • 題目給的算力換算：

     • E 級算力 = $2^{10}$ P hash/sec
     • E 級算力 = $2^{20}$ T hash/sec

   • 這兩個換算關係是矛盾的，因為 $2^{10} \ne 2^{20}$。

     • $2^{10}$ P hash/sec = $2^{10} \times (10^{15})$ hash/sec (假設 Peta = $10^{15}$)
     • $2^{20}$ T hash/sec = $2^{20} \times (10^{12})$ hash/sec (假設 Tera = $10^{12}$)
     • 如果 E 級算力是相同的，那麼 $2^{10} \times 10^{15} \approx 2^{20} \times 10^{12}$。
     • $2^{10} \times 10^3 \approx 2^{20}$
     • $1024 \times 1000 \approx 1048576$
     • $10^6 \approx 10^6$。這個換算似乎是為了連結。

   • 然而，題目後續提到「G 級大約是 $10^9$ hash/sec」。

   • 並且問「1 EB 可以概算為 $10$ 的幾次方位元組?」。

   這暗示題目可能是在問，如果我們有 E 級的算力，它處理的資料量有多大，或者 1 EB 的資料量相當於多少 G 級算力處理的時間。但最直接的理解是，題目給的 P, T, G, E 這些字首，在算力單位和儲存單位中通常有對應的意義。

   在儲存單位中：

   • Kilo (K) = $2^{10}$
   • Mega (M) = $2^{20}$
   • Giga (G) = $2^{30}$
   • Tera (T) = $2^{40}$
   • Peta (P) = $2^{50}$
   • Exa (E) = $2^{60}$

   在科學記號中 (SI units)：

   • kilo (k) = $10^3$
   • Mega (M) = $10^6$
   • Giga (G) = $10^9$
   • Tera (T) = $10^{12}$
   • Peta (P) = $10^{15}$
   • Exa (E) = $10^{18}$

   題目給的「G 級大約是 $10^9$ hash/sec」符合 SI units 的 Giga。
   題目給的「E 級 ... $2^{10}$ 個 P hash/sec, 亦等於 $2^{20}$ 個 T hash/sec」這兩個換算關係，如果 P 和 T 是指 Peta 和 Tera，那麼：

   • E 級 = $2^{10} \times P$ hash/sec = $2^{10} \times 10^{15}$ hash/sec
   • E 級 = $2^{20} \times T$ hash/sec = $2^{20} \times 10^{12}$ hash/sec
   • $2^{10} \times 10^{15} = 1024 \times 10^{15} \approx 10^3 \times 10^{15} = 10^{18}$ hash/sec。

核心觀念：作業系統的排程演算法及其特性，特別是飢餓現象。

飢餓 (Starvation) 是指一個或多個行程（process）在系統中等待了無限長的時間，卻一直無法獲得所需的資源（如 CPU 時間）而無法執行。這通常發生在某些排程演算法中，例如優先權排程，如果一直有高優先權的行程進入系統，低優先權的行程可能永遠無法被執行。

我們來分析各個選項：

(A) 先到先服務 (FCFS, First Come First Served)：

• 這是最簡單的排程演算法，行程按照到達的先後順序執行。
• 一旦行程開始執行，它會一直執行直到完成或主動放棄 CPU。
• 這種方法不會因為行程的優先權或預計執行時間而產生飢餓。每個行程最終都會被執行到，只是等待時間可能很長。
• 不會造成飢餓。

(B) 最短工作優先 (SJF, Shortest Job First)：

• SJF 是一種非先佔式 (non-preemptive) 演算法，它會選擇預計執行時間最短的行程來執行。
• 如果系統中不斷有新的、執行時間非常短的行程到達，那麼一個執行時間較長的行程可能會被無限期地延後。
• 例如，如果行程 A 預計執行 100 秒，而行程 B 預計執行 1 秒。

核心觀念：緩衝區 (Buffer) 的作用與常見資料結構。

當鍵盤輸入速度快於系統處理速度時，需要一個緩衝區來暫時存放輸入的資料，直到系統有能力處理為止。緩衝區的目的是平滑資料流，避免資料遺失。

我們來分析各個選項：

(A) 隨機選擇的雜湊緩衝 (Randomly selected hash buffer)：

• 雜湊緩衝 (Hash Table) 主要用於快速查找，它不適合用來依序處理輸入的資料流。隨機選擇更是與緩衝區需要依序處理的特性不符。

(B) 先進先出的佇列緩衝 (First-In, First-Out queue buffer)：

• 佇列 (Queue) 的特性是「先進先出」(FIFO)。
• 當鍵盤輸入資料時，先輸入的資料會先放入佇列的前端。
• 系統處理資料時，會從佇列的前端取出資料來處理。
• 這種方式能確保輸入的資料按照其輸入的順序被處理，不會因為輸入速度快於處理速度而造成資料遺失。這正是緩衝區的理想行為。

核心觀念：網頁應用程式 (Web Application) 的特性，特別是雲端服務 (Cloud Service) 的運作模式。

題目問的是關於「網頁式簡報處理系統」(Web-based presentation processing system)，並以 Canva 為例。這類系統的關鍵在於「網頁式」，表示它是透過瀏覽器來存取的。

我們來分析各個選項：

(A) 運用 Web 技術建構編輯頁面：

• 網頁式應用程式（如 Canva）的介面都是透過 HTML, CSS, JavaScript 等網頁技術來建構的。編輯頁面、按鈕、拖曳功能等都是在瀏覽器中實現的。
• 此敘述正確。

(B) 必須事先在本機上安裝該簡報處理系統軟體：

• 這是網頁式應用程式 (Web App) 與傳統桌面應用程式 (Desktop App) 的主要區別。

核心觀念：網路診斷工具的用途。

題目要求確認遠端電腦系統是否「啟動連網狀態」，並給定 IP 位址。

我們來分析各個選項：

(A) telnet 140.5.6.7：

• Telnet 是一種用於遠端登入的網路協定和工具。
• 它嘗試與遠端主機的 Telnet 服務 (通常是 TCP port 23) 建立連線。
• 如果 Telnet 連線成功，表示該 IP 位址的主機是啟動的，並且其 Telnet 服務是可用的。這可以間接證明主機在網路上。
• 然而，Telnet 主要用於測試連線到特定服務，如果該主機沒有運行 Telnet 服務，即使主機本身是可達的，Telnet 也會失敗。

(B) ftp 140.5.6.7：

• FTP (File Transfer Protocol) 是一種用於檔案傳輸的協定和工具。
• 它嘗試與遠端主機的 FTP 服務 (通常是 TCP port 21) 建立連線。
• 與 Telnet 類似，FTP 成功連線表示該 IP 位址的主機是啟動的，並且其 FTP 服務是可用的。但如果 FTP 服務未運行，則無法確認主機的可達性。

核心觀念
本題考查電腦病毒、蠕蟲、特洛伊木馬、殭屍網路等惡意程式的定義與特性。

• 病毒 (Computer Virus)：以自我複製方式感染可執行檔或文件，必須透過載入宿主程式才可執行。
• 蠕蟲 (Worm)：自行在網路上傳播，不依賴宿主檔案，常利用安全漏洞或弱密碼自動複製至其他主機。
• 特洛伊木馬 (Trojan Horse)：外表看似合法程式，實際執行惡意行為；本身不具自我複製能力。
• 殭屍網路 (Botnet)：由大量被控制的電腦組成，常用於發起 DoS/DDoS 攻擊或發送垃圾郵件。

解題方法
依據上述定義，檢視每個選項敘述是否符合其正確特性。判斷的關鍵在於：

1. 是否描述了自我複製/感染機制？
2. 是否描述了傳播方式（依賴宿主 vs 網路自動散播）？
3. 是否說明了控制與使用方式（如被遠端指令操控）？

選項分析

選項	敘述	正確性	說明
(A)	「特洛伊木馬程式以密碼字典來猜測密碼，待猜中登入電腦後竊取資料」	不正確	特洛伊木馬本身不具備「以密碼字典猜測密碼」的功能，此屬於 **暴力破解 (brute‑for

核心觀念：勒索病毒 (Ransomware) 的特性與預防措施。

勒索病毒會加密使用者的檔案，然後要求支付贖金以換取解密金鑰。一旦檔案被加密，通常很難（甚至不可能）在沒有金鑰的情況下解密。因此，預防措施的重點在於如何避免檔案被加密，或者在檔案被加密後仍能恢復。

我們來分析各個選項：

(A) 若真的不小心中毒時,再透過線上支付費用取得解密金鑰：

• 這是勒索病毒最希望使用者採取的行動。
• 支付贖金並不保證能收到解密金鑰，即使收到金鑰，也可能解密不完全，或者金鑰無效。
• 支付贖金也會助長勒索病毒的囂張氣焰，鼓勵攻擊者繼續進行攻擊。
• 這不是預防措施，而是中毒後的應對措施，而且是風險極高且不推薦的措施。
• 不是適合的預防措施。

(B) 租用雲端儲存空間且設定自動同步檔案：

• 雲端儲存（如 Google Drive, Dropbox, OneDrive）提供方便的檔案備份和同步功能。
• 如果設定為自動同步，當檔案在本地被修改（包括被加密）時，雲端上的版本也會被更新。
• 然而，如果勒索病毒加密了檔案，並且同步功能是即時的，那麼雲端上的檔案也會被加密的副本覆蓋。

核心觀念：雜湊技術 (Hashing) 在搜尋中的應用。

雜湊技術是一種將任意大小的資料轉換為固定大小的鍵值 (key) 的過程，這個鍵值稱為雜湊值 (hash value) 或雜湊碼 (hash code)。這個過程通常使用一個雜湊函數 (hash function)。

核心概念：

1. 映射 (Mapping)： 雜湊函數將輸入資料（鍵）映射到一個雜湊表中特定位置（索引或桶，bucket）的過程。
2. 固定大小的輸出： 無論輸入資料有多大，雜湊函數產生的雜湊值通常具有固定的長度。
3. 快速計算： 理想情況下，雜湊函數的計算應該非常快速。

運作原理 (用於搜尋)：

雜湊技術用於搜尋的基礎是建立一個雜湊表 (Hash Table)，也被稱為雜湊對映 (hash map) 或字典 (dictionary)。

1. 建構雜湊表：

   • 首先，需要選擇一個合適的雜湊函數 $h(key)$。
   • 當要儲存一個鍵值對 (key-value pair) 時，會先計算鍵的雜湊值：$index = h(key)$。
   • 這個雜湊值 $index$ 會被用來決定該鍵值對在雜湊表中的儲存位置。通常，這個 $index$ 會被轉換成一個陣列的索引。
   • 雜湊表通常是一個陣列，陣列的每個元素稱為一個「桶」(bucket) 或「槽」(slot)。

2. 搜尋操作：

   • 當要搜尋一個特定的鍵 (key) 時，同樣地，首先計算該鍵的雜湊值：$index = h(key)$。
   • 然後，直接前往雜湊表中由 $index$ 指定的位置（桶）查找對應的資料。

優點：

• 平均時間複雜度為 O(1)： 在理想情況下（即雜湊函數能均勻分布雜湊值，且沒有或很少發生碰撞），雜湊表的搜尋、插入和刪除操作的平均時間複雜度都是常

核心觀念：雜湊技術在不可否認性 (Non-repudiation) 中的應用。

不可否認性是指確保一個實體（人或系統）不能否認其已發送或接收了某項資訊，或者執行了某項操作。在數位世界中，這通常透過數位簽章來實現，而雜湊技術是數位簽章的重要組成部分。

核心概念：

1. 資料完整性 (Data Integrity)： 雜湊函數可以產生資料的「數位指紋」。任何對原始資料的微小修改都會導致雜湊值發生劇烈變化。
2. 關聯性 (Binding)： 雜湊值與原始資料緊密關聯。攻擊者無法在不改變雜湊值的情況下修改原始資料，反之亦然。
3. 單向性 (One-way Function)： 好的雜湊函數是單向的，即很難從雜湊值反推回原始資料。這保證了即使雜湊值被洩露，原始資料也不會輕易暴露。

運作原理 (結合數位簽章)：

雜湊技術本身不提供不可否認性，但它與非對稱加密（公鑰/私鑰）結合，構成了數位簽章的核心，從而實現不可否認性。

1. 產生雜湊值： 發送方對要傳送的訊息或文件進行雜湊運算，得到一個固定長度的雜湊值（數位指紋）。

   • 例如：訊息 $M$，雜湊函數 $h$，則得到雜湊值 $H = h(M)$。

2. 數位簽章 (加密雜湊值)： 發送方使用自己的私鑰來加密這個雜湊值。這個加密後的雜湊值就是數位簽章。

   • 發送方將原始訊息 $M$ 和數位簽章 $S = Encrypt_{PrivateKey}(H)$ 一起傳送給接收方。

3. 驗證數位簽章 (解密雜湊值)：

   • 接收方收到訊息 $M'$ 和數位簽章 $S'$。

核心觀念：雜湊技術在區塊鏈 (Blockchain) 中的應用。

區塊鏈是一種去中心化、分散式帳本技術，其中交易記錄被打包成「區塊」(block)，並按照時間順序鏈結在一起。雜湊技術在區塊鏈中扮演著至關重要的角色，主要體現在以下幾個方面：

1. 區塊的連結 (Linking Blocks)：

   • 每個區塊都包含一個指向前一個區塊的雜湊值。
   • 具體來說，當一個新的區塊被創建時，它會包含前一個區塊的雜湊值（稱為「前一區塊雜湊值」，previous hash）。
   • 這個 previous hash 就像一個鏈結，將當前的區塊連接到前一個區塊，形成一個鏈。
   • 運作原理： 如果有人試圖修改鏈中某個區塊的資料，該區塊的雜湊值就會改變。由於下一個區塊中記錄的前一區塊雜湊值不再匹配，整個鏈的連續性就會被破壞，這使得篡對區塊鏈進行篡改變得極其困難。

2. 區塊的完整性 (Block Integrity)：

   • 每個區塊本身也包含一個雜湊值，這個雜湊值是根據該區塊內的所有資料（包括交易記錄、時間戳、前一區塊雜湊值、Nonce 等）計算出來的。
   • 運作原理： 這個區塊雜湊值充當了該區塊的「數位指紋」。任何對區塊內資料的修改都會導致其雜湊值發生變化。這確保了區塊內資料的不可篡改性。

3. 工作量證明 (Proof-of-Work, PoW) - 挖礦 (Mining)：

   • 在許多區塊鏈（如比特幣）中，為了確保新區塊的添加過程是去中心化且安全的，採用了工作量證明機制。
   • 挖礦過程就是要找到一個特定的 Nonce 值，使得將這個 Nonce 值與區塊的內容一起雜湊後，得到的區塊雜湊值滿足特定的條件（例如，雜湊值的前面有一定數量的零）。

核心觀念：組合數的計算，演算法設計與分析。

題目要求設計一個計算組合數 $C_n^k$ 的演算法，並分析其優劣。組合數公式為 $C_n^k = \frac{n!}{k!(n-k)!}$。

直接使用這個公式會遇到一些問題，主要是階乘 (factorial) 的計算，因為 $n!$ 隨著 $n$ 的增大會迅速變得非常大，容易造成整數溢位 (integer overflow)。

我們需要設計一個演算法來避免或減輕這個問題，並考慮效率。

方法一：直接計算階乘 (有溢位風險)

這個方法直接根據公式計算 $n!$, $k!$, $(n-k)!$，然後進行除法。

虛擬碼：

Function CalculateFactorial(num):
  If num is 0 or 1:
    Return 1
  Else:
    result = 1
    For i from 2 to num:
      result = result * i
    Return result

Function CalculateCombinationDirect(n, k):
  If k < 0 or k > n:
    Return 0 // Invalid input
  If k == 0 or k == n:
    Return 1
  If k > n / 2: // Optimization: C(n, k) = C(n, n-k)
    k = n - k

  numerator = CalculateFactorial(n)
  denominator = CalculateFactorial(k) * CalculateFactorial(n - k)

  Return numerator / denominator

優劣分析：

• 優點：
  • 概念簡單，直接對應數學公式。
• 缺點：
  • 嚴重的整數溢位風險： $n!$ 的值增長極快。即使使用 64 位元整數，也只能處理到 $n=20$ 左右 ($20! \approx 2.4 \times 10^{18}$)。對於較大的 $n$，會發生溢位。
  • 計算效率： 計算三個階乘需要較多乘法運算。

方法二：化簡公式並迭代計算 (減少溢位風險，提高效率)

我們可以對公式進行化簡，避免計算完整的階乘。
$C_n^k = \frac{n!}{k!(n-k)!}$
為了簡化，我們假設 $k \le n-k$ (如果不是，可以利用 $C_n^k = C_n^{n-k}$ 的性質交換 $k$ 和 $n-k$，這樣分母的階乘中較大的數字會變成 $n-k$，減少計算量)。
$C_n^k = \frac{n \times (n-1) \times \dots \times (n-k+1)}{k \times (k-1) \times \dots \times 1}$

這個公式表示分子有 $k$ 項，分母也有 $k$ 項。我們可以迭代計算：
從 $i=1$ 到 $k$，每次將結果乘以 $\frac{n-i+1}{i}$。
$C_n^k = \prod_{i=1}^{k} \frac{n-i+1}{i}$

虛擬碼：

Function CalculateCombinationIterative(n, k):
  If k < 0 or k > n:
    Return 0 // Invalid input
  If k == 0 or k == n:
    Return 1
  If k > n / 2: // Optimization: C(n, k) = C(n, n-k)
    k = n - k

  result = 1
  For i from 1 to k:
    // Perform multiplication and division carefully to avoid overflow
    // It's better to do (result * (n - i + 1)) / i
    // Ensure intermediate results do not overflow and division is exact
    // (n - i + 1) is divisible by some factor of i, or result * (n - i + 1) is divisible by i
    // A safe way is to multiply first, then divide, if intermediate can fit
    // Or use rational arithmetic, or check divisibility

    // Example using floating point (can introduce precision errors for very large numbers)
    // result = result * (n - i + 1) / i

    // Example using integer arithmetic with care:
    // We know that C(n, k) is always an integer.
    // The expression (result * (n - i + 1)) must be divisible by i.
    // We can use GCD to simplify, or just multiply then divide if intermediate fits.
    // For competitive programming, often long long is used, and this order works for many cases.
    result = result * (n - i + 1)
    result = result / i

  Return result

處理溢位和精確性的說明：
在 result = result * (n - i + 1) / i 這一步，需要確保 result * (n - i + 1) 不會溢位，並且 result * (n - i + 1) 必須能被 i 整除。由於組合數本身一定是整數，所以數學上來說，這個除法一定是整除的。
在實作時，如果使用標準整數類型（如 int），可能會溢位。使用較大的整數類型（如 long long 在 C++ 中）可以擴大範圍。
更好的做法是：

1. 使用高精度算術庫 (Big Integer Library)： 如果 $n$ 非常大，可能需要使用專門處理大數的庫。

2. 利用 GCD (Greatest Common Divisor)： 在進行乘法和除法之前，可以先用 GCD 來約分，例如：
   term_numerator = n - i + 1
term_denominator = i
common_divisor = GCD(term_numerator, term_denominator)
term_numerator = term_numerator / common_divisor
term_denominator = term_denominator / common_divisor
   然後再計算 result = result * term_numerator / term_denominator。
   或者更常見的，將 result 和 n-i+1 的公因數與 i 進行約分。

   例如：
   result = result * (n - i + 1);
result = result / i;
   若要更安全，可以先對 result 和 i 進行約分，或對 n-i+1 和 i 進行約分。

虛擬碼 (更安全的整數版本)：

Function GCD(a, b):
  While b != 0:
    temp = b
    b = a % b
    a = temp
  Return a

Function CalculateCombinationIterativeSafe(n, k):
  If k < 0 or k > n:
    Return 0
  If k == 0 or k == n:
    Return 1
  If k > n / 2:
    k = n - k

  // Use a data type that can hold potentially large intermediate results, e.g., long long
  result = 1
  For i from 1 to k:
    numerator_term = n - i + 1
    denominator_term = i

    // Simplify the fraction (numerator_term / denominator_term) before multiplying with result
    // This helps reduce intermediate values.
    common_divisor = GCD(numerator_term, denominator_term)
    numerator_term = numerator_term / common_divisor
    denominator_term = denominator_term / common_divisor

    // Now multiply result with the simplified numerator, then divide by the simplified denominator
    // This order is generally safer: result = (result / denominator_term) * numerator_term
    // However, result might not be divisible by denominator_term yet.
    // The safest order is to multiply first, if intermediate result can fit.
    // Or, perform multiplication and division carefully, ensuring divisibility.

    // Let's assume result * numerator_term can fit in the data type.
    // Since C(n,k) is integer, result * numerator_term must be divisible by denominator_term.
    result = result * numerator_term
    result = result / denominator_term

  Return result

核心觀念：RESTful API、用戶端 (Client)、資源 (Resource)、公有雲平台。

此題要求定義 Client 和 Resource，並以公有雲平台為例說明它們與 API 的互動。

定義：

• 用戶端 (Client)：

  • 在軟體架構中，用戶端是指發起請求的一方。
  • 在 Web 應用或 API 的語境下，用戶端通常是使用者介面或應用程式，它需要獲取或操作某種資料或服務。
  • 用戶端不直接與底層的資料庫或業務邏輯互動，而是透過 API 來與伺服器溝通。
  • 常見的用戶端包括：網頁瀏覽器 (執行 JavaScript 的應用)、行動應用程式 (iOS/Android App)、桌面應用程式、其他伺服器應用程式等。

• 資源 (Resource)：

  • 在 RESTful 架構中，資源是 REST 的核心概念。
  • 資源是指任何可以被命名、識別、存取和操作的「東西」。
  • 它可以是：
    • 資料物件： 如使用者資訊、產品列表、訂單記錄、文章內容等。
    • 服務或功能： 如發送郵件、進行支付、查詢天氣等。
    • 集合： 如所有使用者的列表、所有產品的列表。
  • 資源通常透過統一資源識別符 (URI, Uniform Resource Identifier) 來唯一識別。例如，/users/123 可能代表 ID 為 123 的使用者資源。

公有雲平台範例：Amazon Web Services (AWS)

AWS 是一個大型的公有雲平台，提供眾多服務（如 EC2 虛擬機、S3 儲存桶、RDS 資料庫等）。AWS 的許多服務都提供 RESTful API 供用戶（開發者）存取和管理這些雲端資源。

兩者與 API 的互動關係：

以 AWS 的 S3 (Simple Storage Service) 服務為例：

1. 用戶端 (Client)：

   • 例如： 一個部署在 AWS EC2 上的 Web 應用程式，或者一個本地開發者使用的 AWS CLI (Command Line Interface) 工具，甚至是行動應用程式。
   • 角色： 這個 Web 應用程式想要將使用者上傳的圖片儲存到 AWS S3，或者從 S3 下載一個文件。

2. 資源 (Resource)：

   • 例如：
     • 一個特定的 S3 儲存桶 (Bucket)，如 my-unique-bucket-name。
     • 儲存在該儲存桶中的一個物件 (Object)，如 images/user_avatar.jpg。
     • 儲存桶的列表。
     • 物件的元數據 (Metadata)。

3. API (Application Program Interface)：

   • AWS 提供了一個名為 AWS SDK (Software Development Kit) 的介面，其中包含了與 AWS 各項服務互動的 API。對於 RESTful API，AWS 通常會提供基於 HTTP 的 API 端點 (endpoint)。
   • 例如：
     • 要列出帳戶中的所有 S3 儲存桶，用戶端會向 AWS 的 S3 API 端點發送一個 HTTP GET 請求，URI 可能類似於 https://s3.amazonaws.com/ (用於列出儲存桶)。
     • 要上傳一個圖片到指定儲存桶，用戶端會向 https://my-unique-bucket-name.s3.amazonaws.com/images/user_avatar.jpg 發送一個 HTTP PUT 請求，請求體包含圖片的二進位資料。
     • 要下載一個物件，用戶端會向 https://my-unique-bucket-name.s3.amazonaws.com/images/user_avatar.jpg 發送一個 HTTP GET 請求。

互動流程：

1. 用戶端發起請求： Web 應用程式需要儲存圖片，它會呼叫 AWS SDK 中的 S3 上傳方法。
2. SDK 構建 API 請求： SDK 會根據應用程式提供的參數（如儲存桶名稱、物件名稱、圖片資料），構建一個符合 AWS S3 RESTful API 規範的 HTTP 請求。這包括：

核心觀念：REST 架構風格的六項約束 (Constraints)。

REST (Representational State Transfer) 是一種軟體架構風格，用於設計網路應用程式的 API。它由 Roy Fielding 在其博士論文中提出，並基於 HTTP 協定。REST 有六項主要約束，這些約束共同定義了一個 RESTful 系統的行為。

本題要求說明其中兩項約束。

REST 的六項約束：

1. Client-Server (用戶端-伺服器)： 這是 REST 的基本原則，將用戶端和伺服器分開。用戶端負責使用者介面，伺服器負責資料儲存和處理。這種分離使得用戶端和伺服器可以獨立演進。
2. Stateless (無狀態)： 伺服器不應儲存用戶端的任何上下文資訊。每個請求都必須包含所有必要的信息，以便伺服器能夠獨立處理該請求。伺服器不會記住上一個請求的任何資訊。
3. Cacheable (可快取)： 伺服器的響應應該標示為可快取或不可快取。如果響應是可快取的，用戶端或中間的代理伺服器可以重複使用該響應來處理後續的相同請求，從而提高效能並減少伺服器負載。
4. Uniform Interface (統一介面)： 這是 REST 最核心的約束之一，它簡化和解耦了用戶端和伺服器之間的互動。統一介面又可以細分為幾個子約束：
   • Identification of resources (資源識別)： 透過 URI 來識別資源。
   • Manipulation of resources through representations (透過表示來操作資源)： 用戶端獲取資源的表示 (representation)，然後修改這個表示，再將修改後的表示傳送回伺服器以更新資源。
   • Self-descriptive messages (自述性訊息)： 每個訊息都應包含足夠的資訊，以便接收方能夠理解如何處理該訊息（例如，HTTP 標頭中的 Content-Type 說明了請求體或響應體的格式）。
   • Hypermedia as the engine of application state (HATEOAS)： 用戶端可以透過響應中的超媒體連結來發現可用的操作和資源，而不需要預先知道所有 URI。
5. Layered System (分層系統)： 用戶端通常不知道它是否直接連接到最終的伺服器，還是透過中間的代理伺服器、快取伺服器等。這種分層結構提高了系統的可擴展性、可維護性和安全性。
6. Code on Demand (可選)： 伺服器可以臨時擴展用戶端的功能，通過傳輸可執行程式碼（如 JavaScript）給用戶端。

---

選擇兩項進行說明：

這裡我們選擇說明 Stateless (無狀態) 和 Uniform Interface (統一介面)。

1. Stateless (無狀態)

• 說明： 在 RESTful 架構中，伺服器不應在請求之間儲存關於用戶端狀態的任何資訊。這意味著，每個來自用戶端的請求都必須包含所有必要的信息，伺服器可以完全獨立地處理它。伺服器不會依賴於之前請求的上下文。
• 運作原理：
  • 當用戶端向伺服器發送請求時，它必須包含所有必要的資訊，例如認證憑證（如 API 金鑰或 Token）、要操作的資源的識別符（URI）、以及任何操作所需的參數。
  • 伺服器接收到請求後，根據請求中的資訊執行操作，並返回響應。伺服器不會在內部記錄「該用戶端剛剛做了什麼」。
• 優點：
  • 可擴展性 (Scalability)： 由於伺服器不需要維護大量用戶端的狀態，它更容易擴展。新的伺服器實例可以輕鬆地加入集群，因為它們不需要共享用戶端狀態。
  • 可靠性 (Reliability)： 如果伺服器發生故障，不會丟失用戶端正在進行的會話狀態，因為狀態不在伺服器上。
  • 可見性 (Visibility)： 每個請求都包含所有必要資訊，更容易進行監控和調試。
• 缺點：
  • 需要額外的資訊傳輸： 用戶端每次都需要重新傳輸狀態資訊（如認證），這可能會增加網路傳輸的開銷。但通常這與可擴展性和可靠性的優勢相比是值得的。

2. Uniform Interface (統一介面)

• 說明： 統一介面是 REST 的核心，它規定了用戶端與伺服器之間互動的方式必須是統一的、標準化的，而不是隨機的。這使得系統的整體架構更加簡單，用戶端和伺服器之間更容易解耦。
• 運作原理 (細分為四個子約束)：
  • Identification of resources (資源識別)： 每個資源都必須有一個唯一的識別符，通常是 URI。例如，/users/123 代表 ID 為 123 的使用者資源。

核心觀念：RESTful API 的定義與 REST 架構風格的約束。

RESTful API 是遵循 REST 架構風格的 Web API。REST 架構風格有六項約束。題目問的是哪一項「不是」RESTful API 的「必要條件」。

REST 的六項約束是：

1. Client-Server (用戶端-伺服器)
2. Stateless (無狀態)
3. Cacheable (可快取)
4. Uniform Interface (統一介面)
5. Layered System (分層系統)
6. Code on Demand (可選)

通常認為前五項是 RESTful 的核心或必要條件，而 Code on Demand (可選) 是 REST 的一個可選約束。

核心觀念：RESTful API 的組成要素 (URI, HTTP Method, Content-Type) 及其實例應用。

RESTful API 的設計原則是將操作對象抽象為「資源」(Resources)，並透過標準化的方式（HTTP 方法）來對這些資源進行操作。URI 用來識別資源，HTTP 方法指定操作，Content-Type 則描述傳遞資料的格式。

題目要求以「網路商店下單購買商品」為例，說明 RESTful API 的三個組成部分：Nouns (URI), Verb (HTTP method), Content-Types。

範例情境： 模擬一個網路商店，用戶需要下單購買商品。

1. Nouns (URI - 統一資源識別符)：

• 概念： URI 用來唯一識別 API 暴露的「資源」。在 RESTful 設計中，名詞（Nouns）代表資源。

• 範例：
  * 商品列表資源： /products (代表所有商品的集合)
  * 特定商品資源： /products/{product_id} (例如 /products/12345 代表 ID 為 12345 的商品)
  * 購物車資源： /cart (代表當前用戶的購物車)
  * 訂單資源： /orders (代表所有訂單的集合)
  * 特定訂單資源： /orders/{order_id} (例如 /orders/98765 代表 ID 為 98765 的訂單)
  * 特定訂單中的商品： /orders/{order_id}/items (代表特定訂單中的商品列表)

• 在「下單購買商品」的過程中，我們主要會與 /cart 和 /orders 相關的資源互動。

2. Verb (HTTP Method - HTTP 方法)：

• 概念： HTTP 方法（也稱為動詞 Verb）用於指定對 URI 所指向的資源執行的操作類型。RESTful API 通常使用標準的 HTTP 方法來實現 CRUD (Create, Read, Update, Delete) 操作。

• 範例：
  * GET： 用於獲取資源的表示。

  • GET /products：獲取所有商品的列表。
  • GET /products/12345：獲取 ID 為 12345 的商品的詳細資訊。
  • GET /cart：獲取當前購物車中的商品列表。
  • GET /orders/98765：獲取 ID 為 98765 的訂單詳情。
    * POST： 用於創建一個新的資源。
  • POST /cart：向購物車中添加一個新商品。（通常是將商品資訊放在請求體中）
  • POST /orders：創建一個新的訂單（下單）。這通常是「下單購買」的核心操作。用戶會將購物車中的商品資訊、收貨地址等數據放在請求體中。
    * PUT： 用於更新一個現有資源，如果資源不存在則可能創建。
  • PUT /cart：更新購物車的內容（例如，替換整個購物車的商品列表）。
  • PUT /products/12345：更新 ID 為 12345 的商品資訊（通常需要管理員權限）。
    * PATCH： 用於部分更新一個現有資源。
  • PATCH /cart：更新購物車中某個商品的數量。
  • PATCH /orders/98765：部分更新訂單資訊，例如更新收貨地址（如果訂單尚未處理）。
    * DELETE： 用於刪除一個資源。
  • DELETE /cart：清空購物車。
  • DELETE /cart/items/{product_id}：從購物車中移除某個商品。
  • DELETE /orders/98765：刪除一個訂單（通常只能刪除未處理的訂單）。

• 在「下單購買商品」的核心操作中，我們最常使用 POST /orders。

3. Content-Types (內容類型)：

• 概念： Content-Type (在 HTTP 請求頭中的 Content-Type 和響應頭中的 Content-Type) 聲明了傳輸的資料格式。它告訴伺服器或用戶端，傳送的內容是哪種類型（如 JSON, XML, Form Data 等），以及如何解析。
• 範例：
  * 請求時 (Request)：
  • 當用戶端透過 POST /cart 添加商品，或透過 POST /orders 下單時，請求體中可能包含商品 ID、數量、用戶 ID、收貨地址等資訊。
  • 如果使用 JSON 格式傳遞這些資訊，請求頭的 Content-Type 會是 application/json。
  • 如果使用表單提交，Content-Type 可能是 application/x-www-form-urlencoded 或 multipart/form-data。
    * 響應時 (Response)：
  • 當用戶端透過 GET /products/12345 獲取商品詳情時，伺服器可能會以 JSON 格式返回商品資訊，此時響應頭的 Content-Type 會是 application/json。
  • 如果返回的是 HTML 頁面，Content-Type 則是 text/html。