Add the function of normalizing request parameters and returning data…

[suifengpiao14]

… format

[fenollp]

What's your use case here?

[suifengpiao14]

Glad to hear from you

1. Format the request parameters to keep the request parameters stable and automatically fill in the default values for example

describe

list user info

METHOD

-POST

parameters

name	required	type	remark	default
token	yes	string	user token
name	no	string	user name
pageSize	no	int	rows per page	20
page	no	int	page	1

response

name	type	describe
id	int	ID
name	string	user name
avatar	string	user avatar picture url
sex	int	sex 1-man,2-woman
age	int	age

request example 1

{
    "token":"abcd"
    
}

request example 2

{
    "token":"abcd",
    "name":"hello"
}

request example 3

{
    "token":"abcd",
    "name":"hello",
    "page":"5"
}

all three example ok, but the parameter structure received by the server is not fixed, and there is no default value, This features ensures that the server always receives a fixed parameter structure

{
    "token":"abcd",
    "name":"hello",
    "page":"5",
    "pageSize":"20"
}

2.according to the interface requirements, only the required data is returned, and redundant data is deleted

for example basic user info api olny need name and avatar attribute ,and normal user info api need all attributes . This features fit it

[Magicking]

What needs to be worked on for this PR to be merged?

[fenollp]

The two apparent intents of this PR should be broken in two:

• a PR setting defaults in request bodies
• a PR discarding properties that are only allowed by additionalProperties != false, although I'm not sold on the general need for this one

[Magicking]

I keep that on my radar for when I have time, you specify « request bodies » but I guess query parameters as well should get their defaults?

[fenollp]

Ah yes my verbiage was poor. I meant default values should be set on requests on the receiving side (and should probably be omitted on the sending side, if only to save as many bytes from going on the wire)

[suifengpiao14]

What needs to be worked on for this PR to be merged?

Thank you for your reply

help me review the code

[suifengpiao14]

The two apparent intents of this PR should be broken in two:

• a PR setting defaults in request bodies
• a PR discarding properties that are only allowed by additionalProperties != false, although I'm not sold on the general need for this one

Thank you for your reply
yes,I agree with you. it should 2 PR

[suifengpiao14]

I keep that on my radar for when I have time, you specify « request bodies » but I guess query parameters as well should get their defaults?

thinks

My requirement is to make a microservice with this library, which is used to verify and standardize the request , response body. The original plan was to start another library to standardize the request and response bodies. However, it was found that the new library was heavily dependent on the current verification library. Therefore, we wanted to add a switch on the existing library to standardize the request and response bodies