最近為專案組提供rest api 時遇到了關於介面引數的傳遞問題，主要是沒有充分考慮到第三方呼叫者的使用方式，應該儘量的去相容公司之前提供出去的介面呼叫方式，這樣可以降低第三方呼叫者的學習成本，儘管之前的方式並不是那麼的推薦，好的做法是即相容老的做法也支援推薦的做法。

對於基於http post介面，Content-type我會優先選擇application/json,但公司之前提供的介面恰恰採用了application/x-www-form-urlencoded，它是表單預設的提交型別，基於key/value形式提交到服務端的。spring mvc是如何接收下面兩種經典資料的? (至於form-data，它即可以傳鍵值對也可以上傳檔案，這裡不涉及到檔案所以只討論下面兩種)：

• Content-type=application/json：需要在引數上增加@RequestBody這個註解，說明引數是從http的requestbody中獲取。

下圖中的引數，是標準的json格式，對前端js非常友好。

• Content-type=application/x-www-form-urlencoded，引數上不能增加@RequestBody的註解

下圖的可以看出引數形式與get請求時，URL後面的引數格式

為什麼不推薦採用application/x-www-form-urlencoded這種型別，它有如下問題：

• 測試困難,就別想通過postman這類工具測試：提交到服務端實際上是一個MultiValueMap(org.springframework.util.MultiValueMap)，如果value中的物件也是一個物件，那麼在構建這個引數時就非常困難，看下它的過程
  • 採用key1=value1&key2=value2這種形式將所有引數拼接起來，從一長串字元中想了解每個引數的含義沒有個好眼力怕是不行。
  • value要進行編碼，編碼之後的對除錯者不友好。
  • value是複雜物件的情況更加糟糕，一般只能通過程式來序列化得到引數，想手寫基本不可能。
• 客戶端呼叫複雜

需要去構建List<NameValuePair>，一般頁面傳遞的引數都是一個實體物件Model，需要額外的將這個Model轉換成List<NameValuePair>，如果這個物件複雜，那麼構建這個Key/Value就夠人煩的了。這裡給一個java通過apache httpclient呼叫的對比，看看哪一個簡單。

• • application/x-www-form-urlencoded

需要手工將model轉換成NameValuePair。

• • application/json

這裡只需要Model即可，不需要二次轉換，結構也非常清楚。

• key/value的語言表達形式沒有json強，下面兩種你更加喜歡哪一個呢？
  • 字串

post man這類模似http請求的工具中，如果key對應的value是個物件，那麼你需要通過工具得到它的序列化之後的字串然後填寫到欄位中，想想都煩。如果你說我不需要通過這些模似工具測試，那就另當別論

• • json

• 資料結構更加複雜

如果需要提交的物件非常複雜，屬性非常多，如果將所有的屬性都構建到MultiValueMap中，那個Map的構建會非常複雜，試想如果物件有多級巢狀物件呢。所有為了避免這個問題，我們將需要提交的業務物件做為一個key來儲存，value就是物件序列化之後的字串。再加了一些非業務引數，比如安全方面的token等引數，有效的降低了MultiValueMap構建的複雜度。但這種方式相對於json的傳遞方式來講層次更深。如下圖，我們的引數多了一層,jsonParam。

如果解決呢？
不能不相容現有的模式，但又想支援json，焦點就是在引數的接收上，讓其能夠完美的相容上述兩種引數傳遞，這裡可以從HttpMessageConverter著手，這個就是用來將請求的引數對映到spring mvc方法中的實體引數的。我們可以編寫一個自定義的類，內部借用FormHttpMessageConverter來接收MultiValueMap，即使方法引數上增加了@RequestBody的註解，也會走我們自定義的converter，就有機會去重新給引數賦值。

這個方法中需要解決一個問題，就是客戶端傳遞時每個引數都是當成字串來處理的，這種導致我們通過FormHtppMessageConverter轉換成Map時，原本是物件的屬性被識別成字串，而不是object，結果就是在反序列化時會出錯。好在，上面我們將需要提交的物件包裝了一次，產生一個公共的object引數jsonParam，只需要處理這一個特殊物件。做法就是從Map取出jsonParam，然後對其內容進行反序列化，更新Map值，再次進行反序列化就正常了。

上圖中的做法目前有如下問題

• 序列化的欄位是約定好的，也是基於我們的post model基本上來處理的，是針對性的converter
• 程式碼最後面呼叫的jackon的convertValue，對需要反序列化的物件型別有要求，好像不支援泛型型別，比如這種型別的就不行： CommonParamInfoDto<SearchParamInfo<ProductSearchInfo>>

完整的conveter程式碼如下，其實主要程式碼就是上圖貼圖中的那麼對特定欄位的序列化處理，其它的方法都是預設即可。

public class ObjectHttpMessageConverter implements HttpMessageConverter<Object> {

    private final FormHttpMessageConverter formHttpMessageConverter = new FormHttpMessageConverter();
    private final ObjectMapper objectMapper = new ObjectMapper();

    private static final LinkedMultiValueMap<String, ?> LINKED_MULTI_VALUE_MAP = new LinkedMultiValueMap<>();
    private static final Class<? extends MultiValueMap<String, ?>> LINKED_MULTI_VALUE_MAP_CLASS
            = (Class<? extends MultiValueMap<String, ?>>) LINKED_MULTI_VALUE_MAP.getClass();

    @Override
    public boolean canRead(Class clazz, MediaType mediaType) {
        return objectMapper.canSerialize(clazz) && formHttpMessageConverter.canRead(MultiValueMap.class, mediaType);
    }

    @Override
    public boolean canWrite(Class clazz, MediaType mediaType) {
        return false;
    }

    @Override
    public List<MediaType> getSupportedMediaTypes() {
        return formHttpMessageConverter.getSupportedMediaTypes();
    }


    @Override
    public Object read(Class clazz, HttpInputMessage inputMessage) throws IOException, HttpMessageNotReadableException {
        Map input = formHttpMessageConverter.read(LINKED_MULTI_VALUE_MAP_CLASS, inputMessage).toSingleValueMap();
        String jsonParamKey="jsonParam";
        if(input.containsKey(jsonParamKey)) {
            String jsonParam = input.get(jsonParamKey).toString();
            SearchParamInfo<Object> searchParamInfo = new SearchParamInfo<Object>();
            Object jsonParamObj = JsonHelper.json2Object(jsonParam, searchParamInfo.getClass());
            input.put("jsonParam", jsonParamObj);
        }
        Object objResult= objectMapper.convertValue(input, clazz);
        return objResult;
    }

    @Override
    public void write(Object o, MediaType contentType, HttpOutputMessage outputMessage) throws UnsupportedOperationException {
        throw new UnsupportedOperationException("");
    }
}

配置，寫好了conveter之後，需要在配置檔案中配置上才能生效。

最後，我們的方法就可以這樣寫，即可以支援 key/value對，也支援json

我的目的在於api的引數即能支援application/x-www-form-urlencoded也能支援application/json，上面是我目前能想到的辦法，如果大家有其它更好的辦法多多指點。

我又可以愉快的使用post man測試了。而且可以推薦第三方呼叫者優先使用json，我相信這種即能簡化程式設計又方便除錯的優點應該能夠吸引它們。