最近在開發一些http server類型程序,通過spring boot構建一些web程序,這些web程序之間通過http進行數據訪問、共享,如下圖:
假設現在client發起一次保存數據的請求到server,server可能會返回如下類似的數據:
{ "status":1, "message":"xxxxxx" }
然后client通過解析json獲得status來判斷當前的請求操作是否成功,開發過程中通過都是這么做的,但是這樣在restful設計中不怎么好,其實這個status字段的表達完全可以通過http status來表示,類似404、500、502這種都有明確的定義並且相互理解、溝通起來也方便。
文章主要記錄一下我是如何在spring boot中實現自定反饋狀態碼的,以及我找到的三種實現方式。
第一種,使用@ResponseStatus
這是一個注解,可以作用在方法和類上面,如下使用:
在方法上使用方式:
1 @RequestMapping(value = "/user", method = RequestMethod.GET) 2 @ResponseStatus(code=HttpStatus.INTERNAL_SERVER_ERROR,reason="server error") 3 public String getUser(){ 4 return "im zhangsan"; 5 }
啟動web程序,通過postman訪問http://127.0.0.1:8100/user,會出現下面結果:
{ "timestamp": 1497850427325, "status": 500, "error": "Internal Server Error", "message": "server error", "path": "/user" }
這里我一開始覺得很奇怪,為什么我的getUser方法中沒有錯誤,結果還是出現了500錯誤?原因就是@ResponseStatus注解的問題,我后面猜測它會強制的將映射轉化成500的狀態碼。這種應用場景我想不太明白在什么地方會用到。
在類中使用方式:
1 @ResponseStatus(code=HttpStatus.INTERNAL_SERVER_ERROR,reason="111") 2 public class ServerException extends Exception { 3 4 }
這種使用方式就是將自定義異常和狀態碼結合在一起,合理使用自定義異常機制可以最大化的提高程序的健壯性,下面看如何使用:
1 @RequestMapping(value = "/user", method = RequestMethod.GET) 2 public String getUser(@RequestParam String userName) throws ServerException{ 3 if(StringUtils.isEmpty(userName)){ 4 throw new ServerException(); 5 } 6 return "im zhangsan"; 7 }
這段代碼的意思是當userName字段為null的時候會拋出ServerException異常,但是ServerException類被標記了@ResponseStatus注解,因此會直接報500錯誤,如果覺得500不適合還可以定義其它的錯誤代碼。
這種方式看着已經很好了,可以按照邏輯自定義反饋碼,程序夠健壯。這種方式也有不好地方,如果反饋碼太多需要定義太多的異常類,並且錯誤內容reason還是不能手動定義。
到這里,我基本上放棄了@ResponseStatus的使用了。
第二種,使用HttpServletResponse
HttpServletResponse是javax.servlet下的一個接口,如下使用:
1 @RequestMapping(value = "/user", method = RequestMethod.GET) 2 public void getUser(HttpServletResponse response) throws IOException{ 3 response.setStatus(500); 4 response.getWriter().append("server error"); 5 }
這種方式可以很好的實現同時滿足自定義反饋碼+消息內容,一般的實現方式也都是這樣。但是這樣也不是太好,
- 在括號內創建了一個response內置變量,這樣顯得不夠美觀,反而有些多余。
- 在方法中調用了源生的方法來設置反饋碼和消息體,並且如果需要返回json格式數據還需要設置response.setContentType("application/json");和response.setCharacterEncoding("UTF-8");,這樣做有些多余,重復的工作太多,雖然可以進行封裝。
- 最嚴重的問題這個方法必須是void類型,否則就會和@ResponseBody出現沖突,其次就是不能利用@ResponseBody自動封裝json的特性,在spring mvc框架中如果在方法上加上@ResponseBody是可以對返回值自動進行json封裝的。
再找找其他的,如果沒有找到,估計也只能接受這個不完美的東西了。
后來在翻閱spring boot文檔的時候找到了ResponseEntity這么一個東西,這就是我要說的第三種方式。
第三種,使用ResponseEntity
不多說,直接上代碼:
1 @RequestMapping(value = "/user", method = RequestMethod.GET) 2 public ResponseEntity<Map<String,Object>> getUser() throws IOException{ 3 Map<String,Object> map = new HashMap<String,Object>(); 4 map.put("name", "zhangsan"); 5 return new ResponseEntity<Map<String,Object>>(map,HttpStatus.OK); 6 }
通過postman查看返回結果,如下:
{ "name": "zhangsan" }
可以直接將map對象幫我轉化成json對象,並且可以獲得自定義狀態碼,很好,很強大。
這種方式很和我意,
- 不需要多於的HttpServletResponse,看着很干凈。
- 可以充分利用@ResponseBody注解,直接將我的返回值幫我轉化成json對象。
- 在設置返回值的時候同時還可以設置http反饋碼,HttpStatus是springframework提供的一個枚舉類,里面封裝了所有的http反饋碼,方便使用命名統一,不會有任何歧義。
相比於前面兩種,這種方式很對我胃口。
仔細看了ResponseEntity的說明,發現spring mvc其它很多地方也都有使用,如下,下面內容摘自org.springframework.http.ResponseEntity文件注釋,
In RestTemplate, this class is returned by getForEntity() and exchange():
1 ResponseEntity<String> entity = template.getForEntity("http://example.com", String.class); 2 String body = entity.getBody(); 3 MediaType contentType = entity.getHeaders().getContentType(); 4 HttpStatus statusCode = entity.getStatusCode();
Can also be used in Spring MVC, as the return value from a @Controller method:
1 @RequestMapping("/handle") 2 public ResponseEntity<String> handle() { 3 URI location = ...; 4 HttpHeaders responseHeaders = new HttpHeaders(); 5 responseHeaders.setLocation(location); 6 responseHeaders.set("MyResponseHeader", "MyValue"); 7 return new ResponseEntity<String>("Hello World", responseHeaders, HttpStatus.CREATED); 8 }
這就是上面說過的。
Or, by using a builder accessible via static methods:
1 @RequestMapping("/handle") 2 public ResponseEntity<String> handle() { 3 URI location = ...; 4 return ResponseEntity.created(location).header("MyResponseHeader", "MyValue").body("Hello World"); 5 }
自定義http反饋碼在設計優良的restful api中起到關鍵作用,http反饋碼是業內統一、共識的,建議在盡量不要通過解析json來獲得status判斷操作結果。