1 Cast out bricks to attract jade

Let’s start with a very basic piece of business code

Map<String, Object> Map = service. GetDataByName (" GoKu"); Long userId = (Long)map.get("userId"); String phone = (String)map.get("phone");Copy the code

Every time I write this map to get the data back, I feel very uncomfortable

  1. Map is like a bottomless pit, you don’t know what’s inside without looking at the provider codeWhat key did you put in.
  2. When you get the data, you do it yourselfStrong goA little bit of trouble.
  3. This thing has potentialA type conversion exception occurred. Procedure.

2 Request Parameters Request

The first thing to be sure is that it is really convenient to use a map to transfer parameters (front-end HTTP request back-end interface). You don’t need to define a class to stuff whatever data you want into it, as in the following example. You don’t need to define a RequestVo class for each interface

@PostMapping(value = "/map") public ApiResponse testMap(@RequestBody Map<String, Long userId = (Long)map.get("userId"); String phone = (String)map.get("phone"); // Business code... return ApiResponse.ok(); }Copy the code

I don’t like getting data this way, but I also don’t like defining a class to receive it either, because this will cause the number of classes to proliferate, maybe creating a request class for each request interface.

Some additional functions may not be available if they are classed:

  1. Swagger is not a perfectly compatible document.

Don’t want to use Swagger, code is too intrusive, style, directory display is also mediocre, the interface document recommended open source YAPI

Swagger does sometimes come in handy when you add parameters and the code updates at the same time as the document, so you don’t have to maintain the document, but I still don’t like to couple the document with the code.

  1. Validator validation annotations are not available.

I prefer to write the validation logic in controller, it’s more logical.

The original annotations may not be suitable for some complex validations, so you need to customize the annotations, which brings us back to class proliferation

Back to map, map.get (key) is an uncomfortable way to get data, but we can encapsulate the request. For example, in the previous article << when the technical leader said to make the interface RESTful, I rejected the ApiRequest mentioned above.

public class ApiRequest implements Serializable { //.... Private Map<String, Object> data; Public Long getDataParamAsLong(String name, Long defaultValue) {Long I = defaultValue; try{ i = StringUtils.isNotEmpty(getDataParamAsString(name)) ? Long.valueOf(getDataParamAsString(name)) : defaultValue; }catch (Exception e){ e.printStackTrace(); } return i; }}Copy the code
@PostMapping(value = "/test") public ApiResponse test(ApiRequest apiRequest) { Long userId = apiRequest.getDataParamAsLong("userId", 0L); // omit some code.... ApiResponse response = ApiResponse.ok() return response; }Copy the code

This is jSON-oriented programming, not object-oriented programming.

3 Response Parameter Response

As for the returned data, I will generally process the data (structure modification and data integration) according to business requirements after I get the data of the Service at the Controller layer, and finally use map integration and response to give the front end an appropriate structure, rather than return the whole class object when the database finds anything.

I will also define a class ReponseVo to encapsulate some of the current returned data and return it to the front end

That’s a contradiction. You said not to be object oriented.

In some scenarios, the data returned by multiple interfaces is identical and can be shared. For some app developers, they will rely on the backend interface to define their models, and similar data will require the backend to return fields with the same name and structure, so that they can share the model.

This…… Instead of relying entirely on background field names, they can define their own Models.

4 Data transfer at the service layer

A remote method call is made between the server and a local method call is made between the server and a remote method call is made between the server and a local method call. If there are multiple parameters, you need to encapsulate a DTO, preferably without a map.

  1. It’s an interface that we can’t write a document to maintain.
  2. Data deserialization problems (highlighted).

If a method uses caching internally and returns only after json deserialization, it is likely to throw an exception to the caller

Set @postmapping (value = "/setData") public ApiResponse setData(ApiRequest Request) {set @postmapping (value = "/setData") public ApiResponse setData(ApiRequest Request) { Map<String, Object> map = new HashMap<>(); map.put("id", 123L); Map. Put ("name", "GoKu"); stringRedisTemplate.set("KEY_GOKU", JsonUtil.toJsonString(map)); return ApiResponse.ok(); } //get @PostMapping(value = "/getData") public ApiResponse getData(ApiRequest request) { Map<String, Object> map = stringRedisTemplate.get("KEY_GOKU", Map.class); Long id = (Long)map.get("id"); // ClassCastException return apiResponse.ok (); }Copy the code

When a MAP is deserialized using JSON, if the original Integer value is less than the maximum value of int, the field whose type was Long is changed to an Integer after deserialization.

The advantage of JSON serialization is that it is more readable. However, without carrying type information, deserialization can only be done correctly if accurate type information is provided, which is also particularly prone to online problems.

5 concludes

The last few sentences summarize the views of this paper, which only represent personal views

  1. Front-end/mobile end request interface, json programming oriented, using MAP to transmit data, part of the interface return data can be defined as VO class
  2. Method calls between servers, multiple parameters need to define the DTO class to transfer data.
  3. It is extremely important to have a clear and visible interface documentation for front-end and back-end tuning. Don’t forget to write good documentation while writing good code.

Especially want to diss those fields do not write comments, code to add fields and do not synchronize to the document backend developer HHH