從MVC到前後端分離

csdn發表於2015-10-26

　　1. 理解MVC

　　MVC是一種經典的設計模式，全名為Model-View-Controller，即模型-檢視-控制器。

　　其中，模型是用於封裝資料的載體，例如，在Java中一般通過一個簡單的POJO（Plain Ordinary Java Object）來表示，其本質是一個普通的Java Bean，包含一系列的成員變數及其getter/setter方法。對於檢視而言，它更加偏重於展現，也就是說，檢視決定了介面到底長什麼樣子，在Java中可通過JSP來充當檢視，或者通過純HTML的方式進行展現，而後者才是目前的主流。模型和檢視需要通過控制器來進行粘合，例如，使用者傳送一個HTTP請求，此時該請求首先會進入控制器，然後控制器去獲取資料並將其封裝為模型，最後將模型傳遞到檢視中進行展現。

　　綜上所述，MVC的互動過程如圖1所示。

從MVC到前後端分離

　　2. MVC模式的優點與不足

　　MVC模式早在上個世紀70年代就誕生了，直到今天它依然存在，可見生命力相當之強。MVC模式最早用於Smalltalk語言中，最後在其它許多開發語言中都得到了很好的應用，例如，Java中的Struts、Spring MVC等框架。正是因為這些MVC框架的出現，才讓MVC模式真正落地，讓開發更加高效，讓程式碼耦合度儘量減小，讓應用程式各部分的職責更加清晰。

　　既然MVC模式這麼好，難道它就沒有不足的地方嗎？我認為MVC至少有以下三點不足：

每次請求必須經過“控制器->模型->檢視”這個流程，使用者才能看到最終的展現的介面，這個過程似乎有些複雜。
實際上檢視是依賴於模型的，換句話說，如果沒有模型，檢視也無法呈現出最終的效果。
渲染檢視的過程是在服務端來完成的，最終呈現給瀏覽器的是帶有模型的檢視頁面，效能無法得到很好的優化。

　　為了使資料展現過程更加直接，並且提供更好的使用者體驗，我們有必要對MVC模式進行改進。不妨這樣來嘗試，首先從瀏覽器傳送AJAX請求，然後服務端接受該請求並返回JSON資料返回給瀏覽器，最後在瀏覽器中進行介面渲染。

　　改進後的MVC模式如圖2所示。

從MVC到前後端分離

　　也就是說，我們輸入的是AJAX請求，輸出的是JSON資料，市面上有這樣的技術來實現這個功能嗎？答案是REST。

REST全稱是Representational State Transfer（表述性狀態轉移），它是Roy Fielding博士在2000年寫的一篇關於軟體架構風格的論文，此文一出，威震四方！國內外許多知名網際網路公司紛紛開始採用這種輕量級的Web服務，大家習慣將其稱為RESTful Web Services，或簡稱REST服務。]

　　如果將瀏覽器這一端視為前端，而伺服器那一端視為後端的話，可以將以上改進後的MVC模式簡化為以下前後端分離模式，如圖3所示。

從MVC到前後端分離

　　可見，有了REST服務，前端關注介面展現，後端關注業務邏輯，分工明確，職責清晰。那麼，如何使用REST服務將應用程式進行前後端分離呢？我們接下來繼續探討，首先我們需要認識REST。

　　3. 認識REST

　　REST本質上是使用URL來訪問資源種方式。眾所周知，URL就是我們平常使用的請求地址了，其中包括兩部分：請求方式與請求路徑，比較常見的請求方式是GET與POST，但在REST中又提出了幾種其它型別的請求方式，彙總起來有六種：GET、POST、PUT、DELETE、HEAD、OPTIONS。尤其是前四種，正好與CRUD（Create-Retrieve-Update-Delete，增刪改查）四種操作相對應，例如，GET（查）、POST（增）、PUT（改）、DELETE（刪），這正是REST與CRUD的異曲同工之妙！需要強調的是，REST是“面向資源”的，這裡提到的資源，實際上就是我們常說的領域物件，在系統設計過程中，我們經常通過領域物件來進行資料建模。

　　REST是一個“無狀態”的架構模式，因為在任何時候都可以由客戶端發出請求到服務端，最終返回自己想要的資料，當前請求不會受到上次請求的影響。也就是說，服務端將內部資源釋出REST服務，客戶端通過URL來訪問這些資源，這不就是SOA所提倡的“面向服務”的思想嗎？所以，REST也被人們看做是一種“輕量級”的SOA實現技術，因此在企業級應用與網際網路應用中都得到了廣泛應用。

　　下面我們舉幾個例子對REST請求進行簡單描述：

從MVC到前後端分離

　　可見，請求路徑相同，但請求方式不同，所代表的業務操作也不同，例如，/advertiser/1這個請求，帶有GET、PUT、DELETE三種不同的請求方式，對應三種不同的業務操作。

　　雖然REST看起來還是很簡單的，實際上我們往往需要提供一個REST框架，讓其實現前後端分離架構，讓開發人員將精力集中在業務上，而並非那些具體的技術細節。下面我們將使用Java技術來實現這個REST框架，整體框架會基於Spring進行開發。

　　4. 實現REST框架

　　4.1 統一響應結構

　　使用REST框架實現前後端分離架構，我們需要首先確定返回的JSON響應結構是統一的，也就是說，每個REST請求將返回相同結構的JSON響應結構。不妨定義一個相對通用的JSON響應結構，其中包含兩部分：後設資料與返回值，其中，後設資料表示操作是否成功與返回值訊息等，返回值對應服務端方法所返回的資料。該JSON響應結構如下：

{
	"meta": {
		"success": true,
		"message": "ok"
	},
	"data": ...
}

　　為了在框架中對映以上JSON響應結構，我們需要編寫一個Response類與其對應：

public class Response {

    private static final String OK = "ok";
    private static final String ERROR = "error";

    private Meta meta;
    private Object data;

    public Response success() {
        this.meta = new Meta(true, OK);
        return this;
    }

    public Response success(Object data) {
        this.meta = new Meta(true, OK);
        this.data = data;
        return this;
    }

    public Response failure() {
        this.meta = new Meta(false, ERROR);
        return this;
    }

    public Response failure(String message) {
        this.meta = new Meta(false, message);
        return this;
    }

    public Meta getMeta() {
        return meta;
    }

    public Object getData() {
        return data;
    }

    public class Meta {

        private boolean success;
        private String message;

        public Meta(boolean success) {
            this.success = success;
        }

        public Meta(boolean success, String message) {
            this.success = success;
            this.message = message;
        }

        public boolean isSuccess() {
            return success;
        }

        public String getMessage() {
            return message;
        }
    }
}

　　以上Response類包括兩類通用返回值訊息：ok與error，還包括兩個常用的操作方法：success( )與failure( )，通過一個內部類來展現後設資料結構，我們在下文中多次會使用該Response類。

　　實現該REST框架需要考慮許多問題，首當其衝的就是物件序列化問題。

　　4.2 實現物件序列化

想要解釋什麼是物件序列化？不妨通過一些例子進行說明。比如，通過瀏覽器傳送了一個普通的HTTP請求，該請求攜帶了一個JSON格式的引數，在服務端需要將該JSON引數轉換為普通的Java物件，這個轉換過程稱為序列化。再比如，在服務端獲取了資料，此時該資料是一個普通的Java物件，然後需要將這個Java物件轉換為JSON字串，並將其返回到瀏覽器中進行渲染，這個轉換過程稱為反序列化。不管是序列化還是反序列化，我們一般都稱為序列化。

　　實際上，Spring MVC已經為我們提供了這類序列化特性，只需在Controller的方法引數中使用@RequestBody註解定義需要反序列化的引數即可，如以下程式碼片段：

@Controller
public class AdvertiserController {

    @RequestMapping(value = "/advertiser", method = RequestMethod.POST)
    public Response createAdvertiser(@RequestBody AdvertiserParam advertiserParam) {
        ...
    }
}

　　若需要對Controller的方法返回值進行序列化，則需要在該返回值上使用@ResponseBody註解來定義，如以下程式碼片段：

@Controller
public class AdvertiserController {

    @RequestMapping(value = "/advertiser/{id}", method = RequestMethod.GET)
    public @ResponseBody Response getAdvertiser(@PathVariable("id") String advertiserId) {
        ...
    }
}

　　當然，@ResponseBody註解也可以定義在類上，這樣所有的方法都繼承了該特性。由於經常會使用到@ResponseBody註解，所以Spring提供了一個名為@RestController的註解來取代以上的@Controller註解，這樣我們就可以省略返回值前面的@ResponseBody註解了，但引數前面的@RequestBody註解是無法省略的。實際上，看看Spring中對應@RestController註解的原始碼便可知曉：

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
public @interface RestController {

    String value() default "";
}

　　可見，@RestController註解已經被@Controller與@ResponseBody註解定義過了，Spring框架會識別這類註解。需要注意的是，該特性在Spring 4.0中才引入。

　　因此，我們可將以上程式碼進行如下改寫：

@RestController
public class AdvertiserController {

    @RequestMapping(value = "/advertiser", method = RequestMethod.POST)
    public Response createAdvertiser(@RequestBody AdvertiserParam advertiserParam) {
        ...
    }

    @RequestMapping(value = "/advertiser/{id}", method = RequestMethod.GET)
    public Response getAdvertiser(@PathVariable("id") String advertiserId) {
        ...
    }
}

　　除了使用註解來定義序列化行為以外，我們還需要使用Jackson來提供JSON的序列化操作，在Spring配置檔案中只需新增以下配置即可：

<mvc:annotation-driven>
    <mvc:message-converters>
        <bean class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter"/>
    </mvc:message-converters>
</mvc:annotation-driven>

　　若需要對Jackson的序列化行為進行定製，比如，排除值為空屬性、進行縮排輸出、將駝峰轉為下劃線、進行日期格式化等，這又如何實現呢？

　　首先，我們需要擴充套件Jackson提供的ObjectMapper類，程式碼如下：

public class CustomObjectMapper extends ObjectMapper {

    private boolean camelCaseToLowerCaseWithUnderscores = false;
    private String dateFormatPattern;

    public void setCamelCaseToLowerCaseWithUnderscores(boolean camelCaseToLowerCaseWithUnderscores) {
        this.camelCaseToLowerCaseWithUnderscores = camelCaseToLowerCaseWithUnderscores;
    }

    public void setDateFormatPattern(String dateFormatPattern) {
        this.dateFormatPattern = dateFormatPattern;
    }

    public void init() {
        // 排除值為空屬性
        setSerializationInclusion(JsonInclude.Include.NON_NULL);
        // 進行縮排輸出
        configure(SerializationFeature.INDENT_OUTPUT, true);
        // 將駝峰轉為下劃線
        if (camelCaseToLowerCaseWithUnderscores) {
            setPropertyNamingStrategy(PropertyNamingStrategy.CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES);
        }
        // 進行日期格式化
        if (StringUtil.isNotEmpty(dateFormatPattern)) {
            DateFormat dateFormat = new SimpleDateFormat(dateFormatPattern);
            setDateFormat(dateFormat);
        }
    }
}

　　然後，將CustomObjectMapper注入到MappingJackson2HttpMessageConverter中，Spring配置如下：

<bean id="objectMapper" class="com.xxx.api.json.CustomObjectMapper" init-method="init">
    <property name="camelCaseToLowerCaseWithUnderscores" value="true"/>
    <property name="dateFormatPattern" value="yyyy-MM-dd HH:mm:ss"/>
</bean>

<mvc:annotation-driven>
    <mvc:message-converters>
        <bean class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter">
            <property name="objectMapper" ref="objectMapper"/>
        </bean>
    </mvc:message-converters>
</mvc:annotation-driven>

　　通過以上過程，我們已經完成了一個基於Spring MVC的REST框架，只不過該框架還非常單薄，還缺乏很多關鍵性特性，尤其是異常處理。

　　4.3 處理異常行為

　　在Spring MVC中，我們可以使用AOP技術，編寫一個全域性的異常處理切面類，用它來統一處理所有的異常行為，在Spring 3.2中才開始提供。使用法很簡單，只需定義一個類，並通過@ControllerAdvice註解將其標註即可，同時需要使用@ResponseBody註解表示返回值可序列化為JSON字串。程式碼如下：

@ControllerAdvice
@ResponseBody
public class ExceptionAdvice {

    /**
     * 400 - Bad Request
     */
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(HttpMessageNotReadableException.class)
    public Response handleHttpMessageNotReadableException(HttpMessageNotReadableException e) {
        logger.error("引數解析失敗", e);
        return new Response().failure("could_not_read_json");
    }

    /**
     * 405 - Method Not Allowed
     */
    @ResponseStatus(HttpStatus.METHOD_NOT_ALLOWED)
    @ExceptionHandler(HttpRequestMethodNotSupportedException.class)
    public Response handleHttpRequestMethodNotSupportedException(HttpRequestMethodNotSupportedException e) {
        logger.error("不支援當前請求方法", e);
        return new Response().failure("request_method_not_supported");
    }

    /**
     * 415 - Unsupported Media Type
     */
    @ResponseStatus(HttpStatus.UNSUPPORTED_MEDIA_TYPE)
    @ExceptionHandler(HttpMediaTypeNotSupportedException.class)
    public Response handleHttpMediaTypeNotSupportedException(Exception e) {
        logger.error("不支援當前媒體型別", e);
        return new Response().failure("content_type_not_supported");
    }

    /**
     * 500 - Internal Server Error
     */
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler(Exception.class)
    public Response handleException(Exception e) {
        logger.error("服務執行異常", e);
        return new Response().failure(e.getMessage());
    }
}

　　可見，在ExceptionAdvice類中包含一系列的異常處理方法，每個方法都通過@ResponseStatus註解定義了響應狀態碼，此外還通過@ExceptionHandler註解指定了具體需要攔截的異常類。以上過程只是包含了一部分的異常情況，若需處理其它異常，可新增方法具體的方法。需要注意的是，在執行時從上往下依次呼叫每個異常處理方法，匹配當前異常型別是否與@ExceptionHandler註解所定義的異常相匹配，若匹配，則執行該方法，同時忽略後續所有的異常處理方法，最終會返回經JSON序列化後的Response物件。

　　4.4 支援引數驗證

　　我們回到上文所提到的示例，這裡處理一個普通的POST請求，程式碼如下：

@RestController
public class AdvertiserController {

    @RequestMapping(value = "/advertiser", method = RequestMethod.POST)
    public Response createAdvertiser(@RequestBody AdvertiserParam advertiserParam) {
        ...
    }
}

　　其中，AdvertiserParam引數包含若干屬性，通過以下類結構可見，它是一個傳統的POJO：

public class AdvertiserParam {

    private String advertiserName;
    
    private String description;

    // 省略 getter/setter 方法
}

　　如果業務上需要確保AdvertiserParam物件的advertiserName屬性必填，如何實現呢？

　　若將這類引數驗證的程式碼寫死在Controller中，勢必會與正常的業務邏輯攪在一起，導致責任不夠單一，違背於“單一責任原則”。建議將其引數驗證行為從Controller中剝離出來，放到另外的類中，這裡僅提供一個@Valid註解來定義AdvertiserParam引數，並在AdvertiserParam類中通過@NotEmpty註解來定義advertiserName屬性，就像下面這樣：

@RestController
public class AdvertiserController {

    @RequestMapping(value = "/advertiser", method = RequestMethod.POST)
    public Response createAdvertiser(@RequestBody @Valid AdvertiserParam advertiserParam) {
        ...
    }
}

public class AdvertiserParam {

    @NotEmpty
    private String advertiserName;
    
    private String description;

    // 省略 getter/setter 方法
}

　　這裡的@Valid註解實際上是Validation Bean規範提供的註解，該規範已由Hibernate Validator框架實現，因此需要新增以下Maven依賴到pom.xml檔案中：

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>${hibernate-validator.version}</version>
</dependency>

　　需要注意的是，Hibernate Validator與Hibernate沒有任何依賴關係，唯一有聯絡的只是都屬於JBoss公司的開源專案而已。

　　要實現@NotEmpty註解的功能，我們需要做以下幾件事情。

　　首先，定義一個@NotEmpty註解類，程式碼如下：

@Documented
@Target({ElementType.FIELD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = NotEmptyValidator.class)
public @interface NotEmpty {

    String message() default "not_empty";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};
}

　　以上註解類必須包含message、groups、payload三個屬性，因為這是規範所要求的，此外，需要通過@Constraint註解指定一個驗證器類，這裡對應的是NotEmptyValidator，其程式碼如下：

public class NotEmptyValidator implements ConstraintValidator<NotEmpty, String> {

    @Override
    public void initialize(NotEmpty constraintAnnotation) {
    }

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        return StringUtil.isNotEmpty(value);
    }
}

　　以上驗證器類實現了ConstraintValidator介面，並在該介面的isValid( )方法中完成了具體的引數驗證邏輯。需要注意的是，實現介面時需要指定泛型，第一個參數列示驗證註解型別（NotEmpty），第二個參數列示需要驗證的引數型別（String）。

　　然後，我們需要在Spring配置檔案中開啟該特性，需新增如下配置：

    <bean class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor"/>

　　最後，需要在全域性異常處理類中新增引數驗證處理方法，程式碼如下：

@ControllerAdvice
@ResponseBody
public class ExceptionAdvice {

    /**
     * 400 - Bad Request
     */
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(ValidationException.class)
    public Response handleValidationException(ValidationException e) {
        logger.error("引數驗證失敗", e);
        return new Response().failure("validation_exception");
    }
}

　　至此，REST框架已整合了Bean Validation特性，我們可以使用各種註解來完成所需的引數驗證行為了。

　　看似該框架可以在本地成功跑起來，整個架構包含兩個應用，前端應用提供純靜態的HTML頁面，後端應用釋出REST API，前端需要通過AJAX呼叫後端釋出的REST API，然而AJAX是不支援跨域訪問的，也就是說，前後端兩個應用必須在同一個域名下才能訪問。這是非常嚴重的技術障礙，一定需要找到解決方案。

　　4.5 解決跨域問題

　　比如，前端應用為靜態站點且部署在http://web.xxx.com域下，後端應用釋出REST API並部署在http://api.xxx.com域下，如何使前端應用通過AJAX跨域訪問後端應用呢？這需要使用到CORS技術來實現，這也是目前最好的解決方案了。

　　[CORS全稱為Cross Origin Resource Sharing（跨域資源共享），服務端只需新增相關響應頭資訊，即可實現客戶端發出AJAX跨域請求。]

　　CORS技術非常簡單，易於實現，目前絕大多數瀏覽器均已支援該技術（IE8瀏覽器也支援了），服務端可通過任何程式語言來實現，只要能將CORS響應頭寫入response物件中即可。

　　下面我們繼續擴充套件REST框架，通過CORS技術實現AJAX跨域訪問。

　　首先，我們需要編寫一個Filter，用於過濾所有的HTTP請求，並將CORS響應頭寫入response物件中，程式碼如下：

public class CorsFilter implements Filter {

    private String allowOrigin;
    private String allowMethods;
    private String allowCredentials;
    private String allowHeaders;
    private String exposeHeaders;

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        allowOrigin = filterConfig.getInitParameter("allowOrigin");
        allowMethods = filterConfig.getInitParameter("allowMethods");
        allowCredentials = filterConfig.getInitParameter("allowCredentials");
        allowHeaders = filterConfig.getInitParameter("allowHeaders");
        exposeHeaders = filterConfig.getInitParameter("exposeHeaders");
    }

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;
        if (StringUtil.isNotEmpty(allowOrigin)) {
            List<String> allowOriginList = Arrays.asList(allowOrigin.split(","));
            if (CollectionUtil.isNotEmpty(allowOriginList)) {
                String currentOrigin = request.getHeader("Origin");
                if (allowOriginList.contains(currentOrigin)) {
                    response.setHeader("Access-Control-Allow-Origin", currentOrigin);
                }
            }
        }
        if (StringUtil.isNotEmpty(allowMethods)) {
            response.setHeader("Access-Control-Allow-Methods", allowMethods);
        }
        if (StringUtil.isNotEmpty(allowCredentials)) {
            response.setHeader("Access-Control-Allow-Credentials", allowCredentials);
        }
        if (StringUtil.isNotEmpty(allowHeaders)) {
            response.setHeader("Access-Control-Allow-Headers", allowHeaders);
        }
        if (StringUtil.isNotEmpty(exposeHeaders)) {
            response.setHeader("Access-Control-Expose-Headers", exposeHeaders);
        }
        chain.doFilter(req, res);
    }

    @Override
    public void destroy() {
    }
}

　　以上CorsFilter將從web.xml中讀取相關Filter初始化引數，並將在處理HTTP請求時將這些引數寫入對應的CORS響應頭中，下面大致描述一下這些CORS響應頭的意義：

Access-Control-Allow-Origin：允許訪問的客戶端域名，例如：http://web.xxx.com，若為*，則表示從任意域都能訪問，即不做任何限制。
Access-Control-Allow-Methods：允許訪問的方法名，多個方法名用逗號分割，例如：GET,POST,PUT,DELETE,OPTIONS。
Access-Control-Allow-Credentials：是否允許請求帶有驗證資訊，若要獲取客戶端域下的cookie時，需要將其設定為true。
Access-Control-Allow-Headers：允許服務端訪問的客戶端請求頭，多個請求頭用逗號分割，例如：Content-Type。
Access-Control-Expose-Headers：允許客戶端訪問的服務端響應頭，多個響應頭用逗號分割。

　　需要注意的是，CORS規範中定義Access-Control-Allow-Origin只允許兩種取值，要麼為*，要麼為具體的域名，也就是說，不支援同時配置多個域名。為了解決跨多個域的問題，需要在程式碼中做一些處理，這裡將Filter初始化引數作為一個域名的集合（用逗號分隔），只需從當前請求中獲取Origin請求頭，就知道是從哪個域中發出的請求，若該請求在以上允許的域名集合中，則將其放入Access-Control-Allow-Origin響應頭，這樣跨多個域的問題就輕鬆解決了。

　　以下是web.xml中配置CorsFilter的方法：

<filter>
    <filter-name>corsFilter</filter-name>
    <filter-class>com.xxx.api.cors.CorsFilter</filter-class>
    <init-param>
        <param-name>allowOrigin</param-name>
        <param-value>http://web.xxx.com</param-value>
    </init-param>
    <init-param>
        <param-name>allowMethods</param-name>
        <param-value>GET,POST,PUT,DELETE,OPTIONS</param-value>
    </init-param>
    <init-param>
        <param-name>allowCredentials</param-name>
        <param-value>true</param-value>
    </init-param>
    <init-param>
        <param-name>allowHeaders</param-name>
        <param-value>Content-Type</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>corsFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

　　完成以上過程即可實現AJAX跨域功能了，但似乎還存在另外一個問題，由於REST是無狀態的，後端應用釋出的REST API可在使用者未登入的情況下被任意呼叫，這顯然是不安全的，如何解決這個問題呢？我們需要為REST請求提供安全機制。

　　4.6 提供安全機制

　　解決REST安全呼叫問題，可以做得很複雜，也可以做得特簡單，可按照以下過程提供REST安全機制：

當使用者登入成功後，在服務端生成一個token，並將其放入記憶體中（可放入JVM或Redis中），同時將該token返回到客戶端。
在客戶端中將返回的token寫入cookie中，並且每次請求時都將token隨請求頭一起傳送到服務端。
提供一個AOP切面，用於攔截所有的Controller方法，在切面中判斷token的有效性。
當登出時，只需清理掉cookie中的token即可，服務端token可設定過期時間，使其自行移除。

　　首先，我們需要定義一個用於管理token的介面，包括建立token與檢查token有效性的功能。程式碼如下：

public interface TokenManager {

    String createToken(String username);

    boolean checkToken(String token);
}

然後，我們可提供一個簡單的TokenManager實現類，將token儲存到JVM記憶體中。程式碼如下：

public class DefaultTokenManager implements TokenManager {

    private static Map<String, String> tokenMap = new ConcurrentHashMap<>();

    @Override
    public String createToken(String username) {
        String token = CodecUtil.createUUID();
        tokenMap.put(token, username);
        return token;
    }

    @Override
    public boolean checkToken(String token) {
        return !StringUtil.isEmpty(token) && tokenMap.containsKey(token);
    }
}

　　需要注意的是，如果需要做到分散式叢集，建議基於Redis提供一個實現類，將token儲存到Redis中，並利用Redis與生俱來的特性，做到token的分散式一致性。

　　然後，我們可以基於Spring AOP寫一個切面類，用於攔截Controller類的方法，並從請求頭中獲取token，最後對token有效性進行判斷。程式碼如下：

public class SecurityAspect {

    private static final String DEFAULT_TOKEN_NAME = "X-Token";

    private TokenManager tokenManager;
    private String tokenName;

    public void setTokenManager(TokenManager tokenManager) {
        this.tokenManager = tokenManager;
    }

    public void setTokenName(String tokenName) {
        if (StringUtil.isEmpty(tokenName)) {
            tokenName = DEFAULT_TOKEN_NAME;
        }
        this.tokenName = tokenName;
    }

    public Object execute(ProceedingJoinPoint pjp) throws Throwable {
        // 從切點上獲取目標方法
        MethodSignature methodSignature = (MethodSignature) pjp.getSignature();
        Method method = methodSignature.getMethod();
        // 若目標方法忽略了安全性檢查，則直接呼叫目標方法
        if (method.isAnnotationPresent(IgnoreSecurity.class)) {
            return pjp.proceed();
        }
        // 從 request header 中獲取當前 token
        String token = WebContext.getRequest().getHeader(tokenName);
        // 檢查 token 有效性
        if (!tokenManager.checkToken(token)) {
            String message = String.format("token [%s] is invalid", token);
            throw new TokenException(message);
        }
        // 呼叫目標方法
        return pjp.proceed();
    }
}

　　若要使SecurityAspect生效，則需要新增如下Spring 配置：

<bean id="securityAspect" class="com.xxx.api.security.SecurityAspect">
    <property name="tokenManager" ref="tokenManager"/>
    <property name="tokenName" value="X-Token"/>
</bean>

<aop:config>
    <aop:aspect ref="securityAspect">
        <aop:around method="execute" pointcut="@annotation(org.springframework.web.bind.annotation.RequestMapping)"/>
    </aop:aspect>
</aop:config>

　　最後，別忘了在web.xml中新增允許的X-Token響應頭，配置如下：

<init-param>
    <param-name>allowHeaders</param-name>
    <param-value>Content-Type,X-Token</param-value>
</init-param>

　　總結

　　本文從經典的MVC模式開始，對MVC模式是什麼以及該模式存在的不足進行了簡述。然後引出瞭如何對MVC模式的改良，讓其轉變為前後端分離架構，以及解釋了為何要進行前後端分離。最後通過REST服務將前後端進行解耦，並提供了一款基於Java的REST框架的主要實現過程，尤其是需要注意的核心技術問題及其解決方案。希望本文對正在探索前後端分離的讀者們有所幫助，期待與大家共同探討。

從部署上做到前後端分離
2019-08-06
後端
從邏輯解偶到物理解耦再到前後端分離
2014-11-13
解耦後端
一步步從後端渲染到前後端分離經驗分享（1）
2018-08-05
後端
從前後端分離到GraphQL，攜程如何用Node實現？\n
2019-01-23
後端
再談前後端分離
2019-03-01
後端
前後端分離那些事
2019-04-04
後端
淺談前後端分離
2018-12-25
後端
前後端分離——使用OSS
2023-01-29
後端
前後端分離後的前端時代
2017-07-12
後端前端
前後端不分離到分離演變,優勢,前後端介面聯調,排錯及優化
2020-12-03
後端優化
為什麼前後端分離了，你比從前更痛苦？
2018-12-09
後端
???前後端分離模式的思考???
2020-02-27
後端模式
前後端分離——資料mock
2018-08-10
後端Mock
vue前後端分離修改webpack
2018-11-29
Vue後端Web
前後端分離整合SpringSecurity
2020-12-11
後端SpringGse
前後端分離，最佳實踐
2016-11-07
後端
淺談WEB前後端分離
2016-12-27
Web後端
什麼是前後端分離？
2017-10-10
後端
前後端分離實踐有感
2018-01-14
後端
前後端分離Ajax入門
2024-03-15
後端
從零開始搭建前後端分離論壇一
2020-02-26
後端
傳統的MVC開發模式和前後端分離開發模式
2023-10-05
MVC模式後端
Django+Vue.js搭建前後端分離專案 web前後端分離專案實踐
2017-11-01
DjangoVue.js後端Web
Flask前後端分離專案案例
2020-07-24
Flask後端
前後端分離的優缺點
2019-02-27
後端
實現前後端分離的心得
2018-08-31
後端
簡單的前後端分離 Cas
2018-12-27
後端
Laravel 前後端分離 csrf 防護
2018-05-24
Laravel後端
實踐中的前後端分離
2017-10-09
後端
前後端分離之Ajax入門
2024-03-14
後端
前後端分離探索——MVC 專案升級的一個過渡方案
2019-11-12
後端MVC
《從零構建前後分離web專案》探究 - 深入聊聊前後分離架構
2018-09-03
Web架構
前後端分離 Vue + NodeJS(Koa) + MongoDB，從產品到開發，全棧實踐
2018-08-28
後端VueNodeJSMongoDB全棧
前後端分離開發腳手架
2019-02-21
後端
jQuery 前後端分離專案總結
2019-03-03
jQuery後端
用jQuery怎麼做到前後端分離
2019-02-16
jQuery後端
node-vue前後端分離記錄
2019-02-16
Vue後端
前後端分離開發部署模式【轉】
2021-09-09
後端模式

從MVC到前後端分離

1. 理解MVC

2. MVC模式的優點與不足

3. 認識REST

4. 實現REST框架

4.1 統一響應結構

4.2 實現物件序列化

4.3 處理異常行為

4.4 支援引數驗證

4.5 解決跨域問題

4.6 提供安全機制

總結

相關文章

　　1. 理解MVC

　　2. MVC模式的優點與不足

　　3. 認識REST

　　4. 實現REST框架

　　4.1 統一響應結構

　　4.2 實現物件序列化

　　4.3 處理異常行為

　　4.4 支援引數驗證

　　4.5 解決跨域問題

　　4.6 提供安全機制

　　總結