後端面試：什麼時候值得註冊新的頂級媒體類型？

題目與使用情境

你的團隊要在檔案下載、即時媒體和裝置間交換觸覺軌道資料。現有 audio、video 和 application 類型都只能部分表達語義。請依據 RFC 9694 評估是否應註冊新的 haptics 頂級媒體類型，並說明子類型、內容協商、未知實作、版本演進和安全邊界。

面試官考察什麼

• 能否區分頂級類型、具體子類型、參數和檔案格式，不把 MIME 字串當成完整協定。
• 是否會用清楚範圍、至少一個有意義子類型、公開規格、互通和 IANA 註冊要求約束提案。
• 能否設計未知類型、舊客戶端、代理、快取和內容協商的降級路徑。
• 是否識別解譯器、硬體執行、資源耗盡、隱私和人身安全風險，而不是只討論註冊流程。

作答前的釐清問題

先確認資料是否代表獨立的媒體感官、是否已有多個互通格式、是否需要與 audio 或 video 同步，以及客戶端能否安全忽略未知能力。再確認傳輸協定、檔案封裝、即時性、快取策略、裝置能力發現和故障時的使用者體驗。若只有單一私有格式或僅供一個應用內部使用，優先考慮 application 下的子類型或私有註冊，不急於建立頂級類型。

30 秒回答框架

我會先證明現有頂級類型無法準確表達語義，並確認存在多個可互通的子類型和真實部署需求。RFC 9694 要求清楚定義適用範圍和子類型標準，至少描述一個子類型，並完整說明安全考量。若證據成立，就提出 haptics 頂級類型；同時保留舊封裝的相容路徑，定義內容協商、未知子類型處理、參數註冊和回滾策略。實作端預設拒絕危險能力，解析與硬體渲染分離，所有能量、時長和強度參數都要受限。

分步驟深入解答

1. 先判斷類型層級

頂級類型表達一類跨格式的內容語義，子類型表達具體編碼或交換格式，參數補充協商資訊。不要因為出現一個新檔案副檔名就申請頂級類型；先檢查它是否能穩定歸入現有 audio、video、image 或 application 語義，以及是否有跨實作的共同能力。

2. 驗證 RFC 9694 的門檻

提案必須清楚說明哪些內容屬於該類型、哪些內容明確不屬於，避免未來子類型邊界模糊。至少需要一個有實際用途的子類型；只有空的頂級名稱沒有互通價值。提案還應給出公開可審閱的規格、編碼和互通資訊，以及涵蓋全部子類型或重要共性風險的安全章節。

3. 用 haptics 作為案例

RFC 9695 將 haptics 作為獨立感官媒體類型，並註冊 ivs、hjif、hmpg 等子類型。其理由是觸覺資料可能獨立存在，也可能與 audio 或 video 同步；把它塞進 application 會丟失媒體語義。這個案例同時提醒團隊：頂級類型只表達內容類別，不規定每種編碼如何解釋。

4. 設計協商和降級

傳送端應依據 Accept 和裝置能力選擇具體子類型，服務端明確 Vary 維度並避免快取污染。舊客戶端不能理解新類型時，提供 audio 或 video 中的相容封裝、靜態替代或明確不可用狀態。未知子類型不能被當作可執行程式碼；解析器應拒絕不支援的參數並記錄原因。

5. 劃定解析與硬體邊界

把解碼、策略檢查和硬體渲染拆成獨立階段。限制檔案大小、時長、採樣率、幅度和並行任務，防止資源耗盡。觸覺資料可能控制執行器，必須在使用者授權、裝置能力和安全上限內執行；服務端不能只靠 Content-Type 判斷可信度。

6. 規劃註冊和演進

準備 IANA 註冊範本、子類型命名規則、參數和安全章節，說明規格的穩定版本與變更控制者。為新增參數定義向後相容規則；未知參數應按規格忽略或拒絕。記錄觀測指標，包括協商失敗、降級率、解析錯誤、快取命中和裝置安全拒絕，以便決定是否繼續擴大部署。

高品質示範回答

我會先建立「語義、生態、風險」三張表。若資料只是單一應用的私有編碼，使用 application 下的具體子類型；若它代表獨立感官媒體，已有多個可互通格式，並且需要跨檔案、即時流和裝置交換，再依據 RFC 9694 申請頂級類型。提案要給出清楚邊界、至少一個有用子類型、公開規格、互通資訊和涵蓋共性風險的安全章節。RFC 9695 的 haptics 案例說明頂級類型表達媒體語義，具體編碼仍由 ivs、hjif、hmpg 等子類型定義。服務端透過內容協商選擇子類型，舊客戶端取得相容封裝或明確降級；快取按實際協商維度區分。解析、策略檢查和硬體渲染分離，限制大小、時長、強度和並行，並要求裝置能力與使用者授權。未知子類型或危險參數預設拒絕，不把 Content-Type 當作信任邊界。上線後追蹤協商失敗、降級率、解析錯誤和安全拒絕，再決定是否擴大生態。

常見錯誤

• 每出現一種新檔案格式就建立一個頂級媒體類型。
• 只寫 IANA 註冊名稱，不定義範圍、子類型和公開規格。
• 把頂級類型當成編碼格式，導致參數和互通責任混亂。
• 讓未知客戶端把資料當作可執行內容，或忽略代理與快取差異。
• 只校驗 Content-Type，不限制解析資源、硬體能力和使用者授權。

追問及應對

application 下的子類型什麼時候更合適？

當內容主要是應用專用結構、沒有獨立媒體語義、只有一個或少數緊密控制的編碼時，application 子類型更簡單。等到出現跨廠商格式、獨立內容協商和穩定共性能力，再重新評估頂級類型。

新類型如何避免破壞舊客戶端？

讓傳送端提供相容封裝或替代表示，服務端根據 Accept 和裝置能力協商；舊客戶端只看到明確不可用或可渲染的舊類型。快取鍵包含實際協商維度，避免把新表示發給舊客戶端。

觸覺資料的安全邊界是什麼？

解析器限制大小、時長、頻率和強度，渲染器再按裝置安全上限裁剪；必須經過使用者授權和能力檢查。服務端認證、授權和內容校驗獨立於媒體類型，不能因為值為 haptics 就信任負載。