SpringMVC RESTful 配置避坑指南：解決「.*」後綴誤匹配問題

SpringMVC RESTful 配置避坑指南

在 web.xml 中將 DispatcherServlet 映射為 / 是 RESTful 風格的標準做法，但會引入一個隱蔽問題：/a/b/c.do、/a/b/c.html 等帶後綴的請求也會被路由到同一 Controller，破壞語義純粹性。本文提供基於 Filter 的零侵入解決方案。

問題根因

url-pattern>/ 匹配所有路徑，但 .* 後綴請求未被過濾，導致 /user/1.json 和 /user/1 進入同一處理邏輯。

解決方案：前置 Filter 攔截帶點請求

1. web.xml 註冊 Filter（置於 DispatcherServlet 之前）

<filter>
    <filter-name>servletRequest</filter-name>
    <filter-class>cn.tomcat.quickstart.common.filter.ServletRequestFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>servletRequest</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

2. 核心 Filter 實現

public class ServletRequestFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain) throws ServletException, IOException {
        String requestPath = request.getServletPath();
        // 靜態資源已在 web.xml 配置 default servlet 處理，不會進入此 Filter
        if (requestPath.lastIndexOf(".") != -1) {
            // 直接轉發 404，拒絕帶後綴請求
            request.getRequestDispatcher("/WEB-INF/pages/error/404.jsp")
                   .forward(request, response);
        } else {
            filterChain.doFilter(request, response);
        }
    }
}

關鍵點說明

• 靜態資源不受影響：JS/CSS/圖片等通過 <mvc:default-servlet-handler/> 或 Tomcat DefaultServlet 處理，不會進入 SpringMVC 鏈路。
• 零修改業務代碼：Controller 仍按 /a/b/c 設計，無需處理後綴邏輯。
• RESTful 純粹性：強制客戶端通過 Accept Header 協商內容類型，而非 URL 後綴。

替代方案對比

總結

RESTful API 設計應堅持「資源路徑無後綴」原則。通過前置 Filter 過濾帶點請求，是兼容舊版本 SpringMVC、零改動業務代碼的最佳實踐。配合靜態資源獨立處理機制，完美解決誤匹配問題。