最近在重寫一個專案時遇到了許多奇葩問題，這個專案是一個簡單的web後臺專案，基本上全都是增刪改查資料庫的操作。這裡面遇到幾個用spring接收前端post請求的介面。
 基本情況是post請求有四種data引數格式，這些基礎知識在我另一片博文中提到過這裡就不廢話了。主要是因為前端有兩個地方用到了這個介面，但是在用這個介面的時候兩個地方用法都不同，奇葩的c++居然還都解析成功了（其實因為c++沒有對請求引數格式和資料做檢查所以一直沒有問題）。
 一個地方是傳送的是application/json格式，傳送了一個jsonArray資料（資料例子["abc", "bcd"]）這個是沒有問題的正確使用方式。（下面簡稱前者）
 另一個地方是傳送的application/x-www-form-urlencode格式，傳送的也是一個jsonArray資料。（下面簡稱後者）


前者解析方式比較簡單

  @RequestMapping(value = "/check_apps_version",
      method = RequestMethod.POST,
      produces = {"application/json;charset=UTF-8"},
      consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)
  @ResponseBody
  public BaseResponse<List<AppListItem>> checkAppsVersion(ReqCheckAppsVersion requstParam,
      @RequestBody List<String> apps) {
    return new BaseResponse<>();
  }
 

後者這個傳送方式在spring用@RequestBody解析時就很怪異，但是前段是手機APP已經發布出去了沒法修改，只能後端來修改滿足這個奇怪的需求

通過除錯發現後者前端的介面傳過來的引數是"["abc","def"]="這樣子的，本身x-www-form-urlencode是多個kev-value對

的資料格式，所以現在沒有value只有key了，只能通過字串處理來解決了。

  @RequestMapping(value = "/check_apps_version",
      method = RequestMethod.POST,
      produces = {"application/json;charset=UTF-8"},
      consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE)
  @ResponseBody
  public BaseResponse<List<AppListItem>> checkAppsVersionParams(HttpServletRequest request,
 

                                                                ReqCheckAppsVersion requstParam,
                                                                @RequestBody String apps) {
String body = request.getReader().lines().collect(Collectors.joining(System.lineSeparator()));
    return BaseResponse.success();
  }
 

兩種方式，一種是通過@RequestBody把post data解析成string格式，另一種是通過HttpServletRequest解析出整個原始post data。然後做字串處理。

但是在做做這個測試時候我們想了一下會不會有隻有value沒有key的情況，也就是這樣"=["abc","def"]"。

測試結果是用tomcat沒法從HttpServletRequest到這個post data，但是用jetty可以從HttpServletRequest解析到post data。

這個可能是tomcat和jetty的區別吧，還沒有弄清楚什麼原因。但是我們的問題總算是解決了，最大感觸就是前人挖坑後人埋啊。

希望以後能注意一下程式碼健壯性的問題，避免給別人或者自己挖坑。