前面介紹了各種請求參數的注入，這些參數在 HTTP 請求中都是以純文本的方式存在的。在處理參數的時候，往往需要把這些文本參數轉換為 Java 對象。JAX-RS 提供了一些內置的規(guī)則里自動完成這種轉換。

轉換規(guī)則一覽

JAX-RS 提供了四條自動類型轉換規(guī)則，下面我們逐條考察。

原始類型

這個早就見識過了，無需多說。舉例回顧一下：

@GET
@Path("{id}")
public Movie getXxx(@PathParam("id") int id) {/*...*/}
    

提供接受單個 String 參數的構造器的類型

這個也不難理解，JAX-RS 會自動調用該構造器創(chuàng)建一個對象：

public class Style {
    public Style(String name) {/* ... */}
    // ...
}

@GET
@Path("{name}")
public Movie getXxx(@PathParam("name") Style style) {
    // JAX-RS 已自動調用 xxx = new Style(name)
    // ...
}
    

提供靜態(tài)工廠方法 valueOf(String) 的類型

也好理解。特別需要注意的是，所有的枚舉類型都在此列，因為編譯器會自動給枚舉類型加上一個這樣的工廠方法。例如：

public enum Style {/*...*/}

@GET
@Path("{name}")
public Movie getXxx(@PathParam("name") Style style) {
    // JAX-RS 已自動調用 style = Style.valueOf(name)
    // ...
}
    

類型參數滿足前兩個條件的 List<T>、Set<T> 和 SortedSet<T>

這條規(guī)則適用于多值參數，例如查詢參數：

@GET
@Path("xxx")
public Movie getXxx(@QueryParam("style") Set<Style> styles) {
    // JAX-RS 已自動轉換每個 Style 對象并組裝到 Set 中
    // ...
}
    

轉換失敗的處理

如果轉換失敗，JAX-RS 會根據情況自動拋出一個包裝了初始異常，但是帶不同 HTTP 錯誤碼的 WebApplicationException：對矩陣參數（@MatrixParam）、查詢參數 （@QueryParam）或路徑參數（@PathParam）來說為 HTTP 404 找不到，而對頭部參數（@HeaderParam）或 Cookie 參數（@CookieParam）為 HTTP 400 錯誤請求。

在《JAX-RS 從傻逼到牛叉 3：路徑匹配》中，我們已經見過如何使用 @PathParam、@QueryParam 和 @MatrixParam 分別注入 URI 中的路徑參數、矩陣參數和查詢參數，以及如何編程訪問這些參數。本文介紹表單參數、HTTP 頭部參數和 Cookie 參數的注入。

表單參數

HTTP 請求也可以使用提交表單的方式。這時請求方法一般是 POST，當然春哥也無法阻止你用 GET。在前面我們雖然介紹過處理 POST 請求的例子，但那只是利用了 JAX-RS 對 JAXB 的支持，并沒有涉及到對具體請求參數的注入。JAX-RS 提供了 @FormParam 注解來注入 POST 請求的參數，例如：

@POST
public Response createMovie(@FormParam("title") String title) {
    // 此處省略若干行
}
    

這兒省略了 @Consumes 注解，JAX-RS 會自動默認為 @Consumes(MediaType.APPLICATION_FORM_URLENCODED)，也就是 application/x-www-form-urlencoded 格式的請求。如果請求格式為 multipart/form-data，就必須顯示指明：

@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
public Response createMovie(@FormParam("title") String title) {
    // 此處省略若干行
}
    

JAX-RS 還支持文件的上傳和下載，以后再介紹。

HTTP 頭部參數

注入 HTTP 頭部參數簡單得不能再簡單了：

@GET
@Path("xxx")
@Produces(MediaType.TEXT_PLAIN)
public String xxx(@HeaderParam("User-Agent") String userAgent) {
    // 此處省略若干行
}
    

如果有很多頭部參數，為了避免臃腫的參數列表，可以注入一個頭部對象，然后編程訪問頭部參數：

@GET
@Path("xxx")
@Produces(MediaType.TEXT_PLAIN)
public String xxx(@Context HttpHeaders headers) {
    // 此處省略若干行
}
    

Cookie 參數

注入 Cookie 參數同樣的簡單：

@GET
@Path("xxx")
@Produces(MediaType.TEXT_PLAIN)
public String xxx(@CookieParam("userName") String userName) {
    // 此處省略若干行
}
    

如果希望編程訪問，則可以像編程訪問那樣注入一個 HttpHeaders 對象，然后通過它的 getCookies() 方法來獲取所有的 Cookie。

目前我們的電影服務只提供了對電影信息的訪問服務，現(xiàn)在我們要再增加兩項級服務，分別用來訪問導演和演員信息。加上原先的電信信息服務，我們把 URI 統(tǒng)一放到 /ms/rest/service/ 的子路徑下。最先想到的方法就是為這三個 URI 分別寫 JAX-RS 服務：

@Singleton
@Path("service/movie")
public class MovieService {
    // 此處省略若干行
}

@Singleton
@Path("service/director")
public class DirectorService {
    // 此處省略若干行
}

@Singleton
@Path("service/director")
public class ActorService {
    // 此處省略若干行
}
    

這種寫法的缺點就是讓三個本來有點關系（父級 URI 相同）的服務被放到了毫不相干的三個類里面，不一個個類地查看注解難以看出這點關系。為此，JAX-RS 提供了動態(tài)資源綁定的功能，讓我們能夠對這種情況做一些整理。

首先，我們引入一個服務定位器來處理集中管理這三個子級服務：

@Singleton
@Path("service")
public class ServiceLocator {
    @Inject
    private MovieService movieService;
    @Inject
    private DirectorService directorService;
    @Inject
    private ActorService actorService;
    private Map<String, Object> serviceMap;

    @PostConstruct
    private initServiceMap() {
        serviceMap = new HashMap<>();
        serviceMap.put("movie", movieService);
        serviceMap.put("director", directorService);
        serviceMap.put("actor", actorService);
    }

    @Path("{name}")
    public Object locateService(@PathParam("name") String name) {
        Object service = serviceMap.get(name);
        if (service == null) {
            throw new WebApplicationException(Status.SERVICE_UNAVAILABLE);
        }
        return service;
    }
}
    

該類中的 locateService 方法根據服務的名稱返回相應的服務實例，注意該方法只有一個 @Path 注解，因為它并不清楚請求的具體內容；返回對象的類型為 Object，表明動態(tài)資源定位不要求服務類實現(xiàn)相同的接口，只需要它們的方法帶有相應的 JAX-RS 注解，就能夠被 JAX-RS 自動發(fā)現(xiàn)和處理（專業(yè)術語稱為 introspect，內省），以 MovieService 為例：

@Singleton
public class MovieService {
    @GET
    @Path("{id}")
    @Produces(MediaType.APPLICATION_JSON)
    public Movie find(@PathParam("id") int id) {
        Movie movie = movieDao.get(id);
        if (movie != null) {
            return movie;
        } else {
            throw new WebApplicationException(Status.NOT_FOUND);
        }
    }

    // 此處省略若干行
}

這樣，每個請求實際上都由兩個類先后處理。例如，處理請求 GET /ms/rest/service/movie/1 的時候，先由 ServiceLocator 返回相配的服務實例 movieService，然后再由該實例的 find 方法返回結果。比起最開始那三個簡單的類，雖然多了一層調用，但換來了更加清晰的結構。

動態(tài)資源定位是一個非常靈活強大的功能，用好的話，完全可以把 URI 層次整理成一個類似于文件目錄結構的抽象文件系統(tǒng)。

籠子大了什么鳥都有。同樣的道理，不論多么細心地設計 URI 結構，在系統(tǒng)復雜到一定程度后，仍然難以避免路徑沖突。為此，JAX-RS 使用一些規(guī)則來定義路徑匹配的優(yōu)先級。

如果某個請求路徑可以對上多個 URI 匹配模式，那么 JAX-RS 就把可能匹配上的 URI 模式先拼接完整，按照下列規(guī)則依次進行比較，直到找出最適合的匹配模式：

1. 首先，字面字符數量更多的 URI 模式優(yōu)先。“字面字符”就是寫死的路徑段，不包含路徑分隔符 / 和模板參數。例如 /ms/rest/movie/{id : \\d+} 包含 11 個字面字符。
2. 其次，模板參數個數最多的 URI 模式優(yōu)先。例如 /ms/rest/movie/{id : \\d+} 帶一個模板參數。
3. 最后，含正則表達式的模板參數個數最多的 URI 模式優(yōu)先。例如 /ms/rest/movie/{id : \\d+} 帶一個含正則表達式的模板參數。

現(xiàn)在看一個例子。回顧一下，/ms/rest/movie/{id : \\d+} 已經用來根據 ID 獲取電影信息。為了制造麻煩，現(xiàn)在引入 /ms/rest/movie/{title} 來根據電影標題獲取電影信息。先請你猜一猜 /ms/rest/movie/300 代表啥？ID 為 300 的神秘電影，還是我們可愛的勇士？只能跟著規(guī)則一條一條地看：

1. 首先，兩個 URI 匹配模式的字面字符都是 11，下一步。
2. 其次，兩個 URI 匹配模式都帶一個模板參數，下一步。
3. 最后，只有 /ms/rest/movie/{id : \\d+} 帶了一個含正則表達式的模板參數，勝利！所以返回 ID 為 300 的片片。

傳說這三條規(guī)則能夠覆蓋 90% 以上的情景。不過我們馬上就能造出一個打破規(guī)則的東西：/ms/rest/movie/{title : [ \\w]+}。經過測試，/ms/rest/movie/300 會匹配上 /ms/rest/movie/{id : \\d+}。如何解釋？JAX-RS 規(guī)范文檔 3.7.2 定義了完整的匹配規(guī)則，對于這兩個簡單的 URI 匹配模式，似乎一直進行到底都無法比較出優(yōu)先級。莫非有另外的潛規(guī)則？或者是 JAX-RS 的實現(xiàn)（參考實現(xiàn)為 Jersey）自行規(guī)定？但無論如何，搞出這種怪物本身就是一個設計錯誤，所以也不必去深究原因。

JAX-RS 的核心功能是處理向 URI 發(fā)送的請求，所以它提供了一些匹配模式以便簡化對 URI 的解析。樓主在本系列的上一篇文章中已經使用了最簡單的路徑參數，本文將介紹一些稍微高級點的咚咚。

模板參數

前面已經見過用 @Path("{id}") 和 @PathParam("id") 來匹配路徑參數 id。這種匹配方式可以被嵌入到 @Path 注解中的任何地方，從而匹配多個參數，例如下面的代碼用來查找 ID 在某一范圍內的電影：

        @GET
        @Path("{min}~{max}")
        @Produces(MediaType.APPLICATION_JSON)
        public List<Movie> findMovies(@PathParam("min") int min, @PathParam("max") int max) {
    

于是，GET /ms/rest/movie/5~16 就將返回 ID 為 5 到 16 的電影。此處的 min 和 max 已被自動轉換為 int 類型。JAX-RS 支持多種類型的自動轉換，詳見 @PathParam 的文檔。

根據 HTTP 規(guī)范，參數可能會編碼。默認情況下，JAX-RS 會自動解碼。如果希望得到未解碼的參數，只需在參數上再加個 @Encoded 注解。該注解適用于大多數 JAX-RS 注入類型，但并不常用。

模板參數雖然靈活，也可能會帶來歧義。例如想用 {firstName}-{lastName} 匹配一個人的姓名，但恰好某人的名（lastName）含有“-”字符，像 O-live K 這種，匹配后就會變成姓 live-K，名 O。這種場景很難避免，一種簡單的解決方法就是對參數值進行兩次編碼，然后在服務端代碼解碼一次，因為 JAX-RS 默認會進行一次解碼，或者加上 @Encoded 注解，自己進行兩次解碼。

另外，在一個復雜系統(tǒng)中，多個 @Path 可能會造成路徑混淆，例如 {a}-{b} 和 {a}-z 都能匹配路徑 a-z。雖然 JAX-RS 定義了一些規(guī)則來指定匹配的優(yōu)先級，但這些規(guī)則本身就比較復雜，并且也不能完全消除混淆。樓主認為，設計一個 REST 系統(tǒng)的核心就是對 URI 的設計，應當小心處理 URI 的結構，合理分類，盡量保證匹配的唯一性，而不要過度使用晦澀的優(yōu)先級規(guī)則。樓主將在下一篇文章介紹優(yōu)先級規(guī)則。

正則表達式

模板參數可以用一個正則表達式進行驗證，寫法是在模板參數的標識符后面加一個冒號，然后跟上正則表達式字符串。例如在根據 ID 查詢電影信息的代碼中，模板參數 {id} 只能是整數，于是代碼可以改進為：

        @GET
        @Path("{id : \\d+}")
        @Produces(MediaType.APPLICATION_JSON)
        public List<Movie> findMovies(@PathParam("min") int min, @PathParam("max") int max) {
    

冒號左右的空格將被忽略。用正則表達式驗證數據很有局限性，可惜 JAX-RS 目前并不能直接集成 Bean 驗證框架，因此復雜的驗證只能靠自己寫代碼。

查詢參數

查詢參數很常見，就是在 URI 的末尾跟上一個問號和一系列由“&”分隔的鍵值對，例如查詢 ID 為 5 到 16 的電影也可以設計為 /ms/rest/movie?min=5&max=16。JAX-RS 提供了 QueryParam 來注入查詢參數：

        @GET
        @Produces(MediaType.APPLICATION_JSON)
        public List<Movie> findMovies(@DefaultValue("0") @QueryParam("min") int min,
                @DefaultValue("0") @QueryParam("max") int max) {
    

查詢參數是可選的。如果 URI 沒有設定某個查詢參數，JAX-RS 就會根據情況為其生成 0、空字符串之類的默認值。如果要手動設定默認值，需要像上面的代碼一樣用 @DefaultValue 注解來指定。另外還可以加上 Encoded 注解來得到編碼的原始參數。

有的查詢參數是一對多的鍵值對，例如 /xyz?a=def&a=pqr，這種情況只需將注入的參數類型改為 List 即可。

矩陣參數

矩陣參數應該屬于 URI 規(guī)范中的非主流類型，但它實際上比查詢參數更靈活，因為它可以嵌入到 URI 路徑中的任何一段末尾（用分號隔開），用來標識該段的某些屬性。例如 GET /ms/rest/movie;year=2011/title;initial=A 表示在 2011 年出品的電影中查找首字母為 A 的標題。year 是電影的屬性，而 initial 是標題的屬性，這比把它們都作為查詢參數放在末尾更直觀可讀。匹配 URI 的時候，矩陣參數將被忽略，因此前面的 URI 匹配為 /ms/rest/movie/title。矩陣參數可以用 @MatrixParam 來注入：

        @GET
        @Path("title")
        @Produces(MediaType.APPLICATION_JSON)
        public List<String> findTitles(@MatrixParam("year") int year,
                @MatrixParam("initial") String initial) {
    

如果 URI 的多個段中含有相同名稱的矩陣參數，例如 /abc;name=XXX/xyz;name=OOO，這種直接注入就失效了，只能用下面要講的編程式訪問來取得。

編程式訪問

如果簡單的注入不能達到目的，就需要通過注入 PathSegment 或 UriInfo 對象來直接編程訪問 URI 的信息。

一個 PathSegment 對象代表 URI 中的一個路徑段，可以從它得到矩陣參數。它可以通過 @PathParam 來注入，這要求該路徑段必須整個被定義為一個模板參數。例如下面的代碼也可以用來處理 GET /ms/rest/movie/{id}：

        @GET
        @Path("{id}")
        @Produces(MediaType.APPLICATION_JSON)
        public Movie findMovie(@PathParam("id") PathSegment ps) {
    

@PathParam 也可以注入多個段，如果想把 /a/b/c/d 匹配到 /a/{segments}/d，直接注入一個字符串顯然不行，因為 b/c 是兩個路徑段。唯一的選擇是把注入的類型改為 List<PathSegment>。樓主嚴重不推薦用一個模板參數匹配多個路徑段，因為這很容易干擾其他匹配的設計，最后搞成一團亂麻。URI 路徑段應當盡量設計得簡單明晰，再輔以矩陣參數或查詢參數就能應付大多數場景。不論對服務端還是客戶端開發(fā)人員來說，簡潔的 URI 既便于管理，又便于使用。網上有不少關于 URI 設計指南的文章，此處不再贅述。

如果想完全手動解析路徑，則可以用 @Context 注入一個 UriInfo 對象，通過此對象可以得到 URI 的全部信息，詳見 API 文檔。例如：

        @GET
        @Path("{id}/{segments}")
        @Produces(MediaType.PLAIN_TEXT)
        public String getInfo(@PathParam("id") int id, @Context UriInfo uriInfo) {
    

UriInfo 主要用在某些特殊場合下起輔助作用，設計良好的 URI 用普通的注入就能完成大部分匹配。

工欲善其事必先利其器，為此 JAX-RS 提供了這些利器來解析 URI。至于如何用這些器來做出一個好系統(tǒng)，則還是依賴于 URI 本身的設計。

JAX-RS 使用注解進行配置，所以用它開發(fā) REST 風格的服務非常簡單。樓主在本文用一個小例子來說明 JAX-RS 的基本用法。

假設樓主要開發(fā)一個小電影服務，客戶端可以通過請求 URI 對電影進行 CRUD 操作。為簡明起見，這兒不使用數據庫，只在內存中模擬。先用一個非常簡單的 Movie 類，在后續(xù)的文章中根據情況逐步擴充：

        public class Movie {
            private int id;
            private String title;
            // 此處省略若干行
        }
    

嗯，就是一個很普通的 JavaBean，實際項目中可以根據需要加上 @Entity 等注解。接下來看看如何編寫 JAX-RS 服務。

一個 JAX-RS 服務就是一個使用了 JAX-RS 注解來將 HTTP 請求綁定到方法的 Java 類，一共支持兩種類型：單請求對象或單例對象。單請求對象意味著每來一個請求，就創(chuàng)建一個服務對象，在請求結束時銷毀。單例對象則意味著只有一個服務對象處理所有的請求，從而可以在多個請求間維持服務狀態(tài)。JAX-RS 服務可通過繼承 javax.ws.rs.core.Application 來定義，其中的 getClasses 方法返回單請求對象的類型，getSingletons 方法返回單例對象的類型。這兩個方法是可選的。在 Java EE 6 環(huán)境中，如果這兩個方法都返回 null 或者空集合，那么應用程序中的所有 JAX-RS 都將被部署。這時可以用 CDI 的 @javax.inject.Singleton 或者 EJB 的 @javax.ejb.Singleton 注解來指定單例對象。

如果電影服務的上下文根路徑為 http://localhost/ms，而樓主希望將服務部署到 http://localhost/ms/rest 下面，只需要寫一個類：

        @ApplicationPath("rest")
        public class RestApplication extends Application {
        }
    

@ApplicationPath 注解指定所有服務的相對基址，如果為空字符串，則直接使用上下文根路徑。另一種配置方式是在 web.xml 文件中進行聲明，那是為了使 JAX-RS 能在 Servlet 容器（例如 Tomcat）中運行，此處略過。這項配置必不可少，否則無法部署服務。

很好很強大，現(xiàn)在開始編寫電影服務類 MovieService，先看看聲明和初始化：

        @Singleton
        @Path("movie")
        public class MovieService {
            private AtomicInteger ai;
            private ConcurrentMap<Integer, Movie> movieMap;

            @PostConstruct
            private void init() {
                ai = new AtomicInteger();
                movieMap = new ConcurrentHashMap<>();
                int id = ai.getAndIncrement();
                movieMap.put(id, new Movie().setId(id).setTitle("Avatar"));
            }
    

因為樓主只需要一個“內存數據庫”，所以用單例對象即可，此處使用 CDI 的 @javax.inject.Singleton 來聲明單例。@Path 聲明了一個服務，它指示 MovieService 負責處理發(fā)送到 http://localhost/ms/rest/movie 的請求。路徑的拼接方式非常直觀。init 方法帶有 @PostConstruct 注解，因此將在 MovieService 構造完成后立即調用，它向 movieMap 中存入了一個 ID 為 0 的 Movie 對象。為簡化代碼，Movie 的設置方法都返回 this，有點偽造構建者模式的味道。

接下來看看如何處理 HTTP 請求。

GET

GET 請求用于獲取一個或多個資源。在本例中用來獲取一部電影的信息：

        @GET
        @Path("{id}")
        @Produces(MediaType.APPLICATION_JSON)
        public Movie find(@PathParam("id") int id) {
            Movie movie = movieMap.get(id);
            if (movie != null) {
                return movie;
            } else {
                throw new WebApplicationException(Response.Status.NOT_FOUND);
            }
        }
    

該方法標注了 @GET，表示用來處理向 http://localhost/ms/rest/movie/{id} 發(fā)送的 GET 請求。@Path 再次用來綁定路徑，注意其參數 {id}，它帶有花括號，對應 URI 的最后一段，也正好和方法參數 id 的 @PathParam 的值相對應。這種參數還有很多高級用法，以后再介紹。@Produces 注解指定輸出格式為 JSON。JAX-RS 內置了很多格式，詳見 MediaType 的文檔。如果找到了相應 ID 的對象，則將其返回，JAX-RS 會自動加上響應碼 200 OK；否則拋出異常，錯誤碼為 404 Not Found。

例如，通過瀏覽器訪問 http://localhost/ms/rest/movie/0，得到的結果為 {"@id":"0","@title":"Avatar"}。

POST

POST 請求用于創(chuàng)建一個資源。在本例中用來創(chuàng)建一部電影：

        @POST
        @Consumes(MediaType.APPLICATION_JSON)
        public Response create(Movie movie) {
            int id = ai.getAndIncrement();
            movieMap.put(id, movie.setId(id));
            return Response.created(URI.create(String.valueOf(id))).build();
        }
    

由于沒有 @Path 注解，所以 POST 請求的目標就直接是 http://localhost/ms/rest/movie。Consumes 和 @Produces 相反，表示接受的數據類型，此處 JAX-RS 會自動把 JSON 數據轉換為 Movie 對象。返回的響應碼為 201 Created，并且?guī)в兴鶆?chuàng)建資源的 URI。

例如，向 http://localhost/ms/rest/movie 發(fā)送 POST 請求，正文為 {"@title": "007"}，則可以從 FireBug 的網絡監(jiān)控中看到返回的響應碼，以及頭部中 Location 的值為 http://localhost:8080/rest/service/movie/1。多次發(fā)送該 POST 請求，將會創(chuàng)建多個資源，以保證 POST 不是冪等的。

PUT

PUT 請求用于創(chuàng)建或更新一個資源。與 POST 不同，PUT 請求要指定某個特定資源的地址。在本例中用來更新一部電影的信息：

        @PUT
        @Path("{id}")
        @Consumes(MediaType.APPLICATION_JSON)
        public Response update(@PathParam("id") int id, Movie movie) {
            movie.setId(id);
            if (movieMap.replace(id, movie) != null) {
                return Response.ok().build();
            } else {
                throw new WebApplicationException(Response.Status.NOT_FOUND);
            }
        }
    

更新成功就返回 200 OK，否則返回 404 Not Found。這兒先把 movie 對象的 ID 強制改為 URI 所指定的，以免出現(xiàn)不一致。也可以根據需求，將不一致作為異常處理，給客戶端返回一個錯誤碼。

順便啰嗦一句，反正代碼在自己手中，樓主也可以把 PUT 搞成非冪等的，例如將 PUT 當成 POST 來處理，就像以前把 GET 和 POST 一視同仁那樣。不過咱既然在搞 JAX-RS，就還是要沾染一點 REST 風格，嚴格遵守 HTTP 才是。

DELETE

DELETE 請求用于刪除一個資源。在本例中用來刪除一部電影：

        @DELETE
        @Path("{id}")
        public Response delete(@PathParam("id") int id) {
            if (movieMap.remove(id) != null) {
                return Response.ok().build();
            } else {
                throw new WebApplicationException(Response.Status.NOT_FOUND);
            }
        }
    

沒什么特別的，該說的前面都說了。

HEAD 和 OPTIONS 請求就忽略吧，用得不太多，也同樣挺簡單的。

JAX-RS 服務的部署和部署常規(guī) Web 程序一樣，打包成 war 文件就可以了。最后贊一下 NetBeans 可以為 REST 風格的服務自動生成測試頁面，很好用，雖然在 Firefox 下頁面顯示不正常（對此我已經提了一個 bug），但 IE 是可以的。

JAX-RS（JSR 311 - Java™ API for RESTful Web Services，用于 REST 風格的 Web 服務的 Java™ API）是 Java EE 6 規(guī)范的一部分，其目標在于簡化和標準化用 Java 開發(fā) REST 風格的 Web 服務。雖然 Java EE 6 剛出爐的時候，樓主也從頭到尾看過這份規(guī)范，但苦于沒有實際的項目練手，看過又忘了，現(xiàn)在最多算達到大成傻逼的境界。這次邊看邊寫，期望完成后至少能破入小成牛逼。先從 REST 本身開始。

REST（REpresentational State Transfer，代表性狀態(tài)傳輸）自稱是一種風格而非標準，這在樓主看來有炒作的嫌疑。如果僅僅是一種風格，那么不同的框架如何兼容？所以才有 JAX-RS 的誕生。REST 最大的貢獻是帶來了 HTTP 協(xié)議的復興。為什么叫復興呢？本來 HTTP 的功能挺豐富的，可惜長期以來只被用作傳輸數據，大好青年被埋沒了。樓主記得剛開始學 Servlet 的時候，一向是把 doGet 和 doPost 兩個方法一視同仁的，因為書上這么教，很多 Web 框架也這么搞，以至于弄了很久才搞清楚 GET 和 POST 是兩種不同的請求。現(xiàn)在 REST 拍磚說道，HTTP 早就定義好了一堆操作，以前一直被混淆使用，現(xiàn)在應該重新賦予它們本來的意義了，而且如果充分發(fā)揮 HTTP 的功能，完全能夠勝任分布式應用的開發(fā)（傳說中的 SOA）。

SOA 的理念在于將系統(tǒng)設計為一系列可重用的、解耦的、分布式的服務。這也不是新鮮玩意兒了，早期有 CORBA，稍晚有 SOAP 等等。REST 作為后起之秀，能夠快速崛起，也必有其非同尋常的特色。下面一一列舉。

可尋址性（Addressability）

系統(tǒng)中的每個資源都可以通過唯一標識符來訪問。小插一句，“標識”的正確讀音是 biāozhì。REST 使用 URI（統(tǒng)一資源標識符）管理資源的地址。URI 的概念不解釋。一個 URI 可以指向一個或者多個資源。

統(tǒng)一的受限接口（The Uniform, Constrained Interface）

實際上強調了 HTTP 操作的原意。REST 主要使用了 GET、PUT、DELETE、POST、HEAD 和 OPTIONS 這 6 種操作。此處有兩個曾經被忽略的 HTTP 概念：冪等（idempotent）和安全（safe）。冪等應該是 HTTP 從數學借來的一個術語（原始的數學意義樓主也不懂），意味著若干次請求的副作用與單次請求相同，或者根本沒有副作用。GET、PUT、DELETE、HEAD 和 OPTIONS 都是冪等的：GET、HEAD 和 OPTIONS 都是讀操作，容易理解；PUT 用于創(chuàng)建或更新已知 URI 的資源，多次創(chuàng)建或更新同一個資源顯然和一次的效果相同；DELETE 刪除資源，亦然。安全表示操作不會影響服務器的狀態(tài)。GET、HEAD 和 OPTIONS 是安全的。POST 既不冪等又不安全，因為和 PUT 不同，POST 創(chuàng)建資源的時候并不知道資源的 URI，所以多個 POST 請求將會創(chuàng)建多個資源。

面向表象（Representation-Oriented）

表象這個詞有點拗口，傳聞在一個 REST 風格的系統(tǒng)中，服務端和客戶端之間傳輸的咚咚就是表象……表象可以是純文本、XML、JSON……或者自編的山寨格式。唉，不就是數據么？只不過可以用任意的格式來傳輸，因為 HTTP 正文里面啥都能放。Content-Type 頭用來聲明格式，一般是 MIME（多用途因特網郵件擴展），像 text/plain、text/html、application/pdf 這些。MIME 可以帶屬性，例如 text/html; charset=UTF-8。

無態(tài)通信（Communicate Statelessly）

REST 服務器只管理資源，而不會像 Web 服務器一樣記錄客戶的會話狀態(tài)，這些應該由客戶端來管理，如此就能增強 REST 服務器的伸縮性。此處的客戶端可以是客戶端程序、瀏覽器，甚至一個 Web 應用。總之，REST 只負責庫管啦！

HATEOAS

猛詞砸來了！HATEOAS = Hypermedia As The Engine Of Application State，超媒體作為應用狀態(tài)的引擎，怎么看起來比 SaaS（Software as a Service，軟件作為服務）還要嚇人呢？超文本不過是一只紙老虎，超媒體也瞞不過樓主的天眼：超媒體就是是由文字、圖像、圖形、視頻、音頻……鏈成一體的大雜燴！很簡單的一個例子，有些坑爹的電影網站經常發(fā)布一些內嵌了廣告的電影，播放的時候會彈出廣告窗口，里面很多鏈接，你去點兩下就中招了：這個電影文件就算是超媒體。

其實這個詞最關鍵的地方是“狀態(tài)引擎”。例如樓主在去網購，先選了幾個東西，接下來可以干啥呢？可以繼續(xù)選、可以把購物車清空、可以結賬……樓主可以從現(xiàn)狀“轉換”到其他某些狀態(tài)，而控制狀態(tài)轉換的那個咚咚就被冠名為狀態(tài)引擎。多么聰明的詞匯啊！樓主發(fā)現(xiàn)凡是高手都是造詞磚家呀！用超媒體來控制狀態(tài)轉換，就是 HATEOAS：你是要繼續(xù)看電影還是看廣告？看哪個廣告？自己慢慢考慮……

REST 相比 CORBA、SOAP、WS-* 之流確實獨樹一幟，但也難逃玩弄概念的嫌疑。記得大學里講數據庫的老師說過：“你們現(xiàn)在學了這么多理論，其實以后在工作中未必管用。在大街上隨便找一個軟件培訓學校出來的小伙子，他哪兒懂什么第二第三范式啊？但卻能把數據庫玩兒得飛轉！”