@shuaijinchao Thank you for your attension.And I think these two questions 
are actually same.
Most of the time, we need a random response generated based on JSON SCHEMA, 
because we usually define only the type of the response parameter, not the 
value of the parameter, when defining the API.
So when we need a random response based on JSON SCHEMA, we use the 
`response_schema` param, and when we need a fixed response we use the 
`response_example` param.
Comparing the two plugins,the `mocking` plugin focuses more on mock the 
response body of real apis while the `fault-injection` focuses more on 
mock the delay of apis.
By the way, the 'mocking' plugin will next support returning different response 
body based on different request headers and params.






------------------ ???????? ------------------
??????:                                                                         
                                               "dev"                            
                                                        
<shuaijinc...@apache.org&gt;;
????????:&nbsp;2022??1??5??(??????) ????7:09
??????:&nbsp;"dev"<dev@apisix.apache.org&gt;;

????:&nbsp;Re: [Proposal] api mocking plugin: generate mock response for 
debegging,testing or pressure measurement.



Hi, @EH Thank you very much for your suggestions

I have two questions:
1. Why is JSON response independent, instead of `response_body` that
combines `response_example` and `response_schema` into one?
2. Do you think the `fault-injection`[1] plugin can meet the current needs?

[1]
https://github.com/apache/apisix/blob/master/docs/zh/latest/plugins/fault-injection.md

EH <rui1...@foxmail.com&gt; ??2021??12??31?????? 15:43??????

&gt; *Background*
&gt; usualy when we develop a new feature on website or miniprogram or mobile
&gt; application, we go through 3 steps:
&gt; 1. design api documents,include api path,paramter,response;
&gt; 2. develop frontend and backend at the same time;
&gt; 3. testing and debugging the frontend and backend program.
&gt;
&gt; in step 2, the frontend need to mock the api??s parameter and response,to
&gt; debug program,and if there??s multiple front-end applications,each app need
&gt; to do mock.
&gt;
&gt; consider this scenario,if our api gateway can support api mocking,the
&gt; steps 2 will come down to:
&gt; 1. turn on mocking plugin when backend is still developing apis.
&gt; 2. turn off mocking plugin when the api is finished.
&gt; and there is nothing need to do for frontend developer,even neednt to
&gt; change the api url.
&gt;
&gt; based on the above scenario, the mocking plugin can be use in more
&gt; scenario,such as:
&gt;
&gt;&nbsp;&nbsp;&nbsp; - when we pressure test the APISIX. we can use the 
mocking plugins to
&gt;&nbsp;&nbsp;&nbsp; mock duration of api and status and response,instead of 
real upstream.
&gt;&nbsp;&nbsp;&nbsp; - in microservice invocation chain,we can mock service 
one by one to
&gt;&nbsp;&nbsp;&nbsp; find the&nbsp; abnormal service.
&gt;
&gt; *Plugin Design*
&gt; this plugin design is reference to mock.js
&gt; <https://github.com/nuysoft/Mock/wiki/Mock.Random&gt; and kong's mocking
&gt; plugin <https://docs.konghq.com/hub/kong-inc/mocking/&gt;.
&gt; it is planned to be implemented in two phases.
&gt;
&gt; phase 1, goal to implement base mock abilities.
&gt; the general design is as follows:
&gt;
&gt; local schema = {
&gt;&nbsp;&nbsp;&nbsp;&nbsp; type = "object",
&gt;&nbsp;&nbsp;&nbsp;&nbsp; properties = {
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- specify response delay 
time,default 0ms
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; delay = { type = "integer" 
},
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- specify response 
status,default 200
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; response_status = { type = 
"integer" },
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- specify response 
content type,support application/xml,text/plain and application/json,default 
application/json
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; content_type = { type = 
"content_type" },
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- specify response body.
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; response_example = {type = 
"string"},
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- specify response json 
schema,if response_example is not nil,this conf will be ignore.
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- generate random 
response by json schema.
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; response_schema = { type = 
"object" },
&gt;&nbsp;&nbsp;&nbsp;&nbsp; },
&gt;&nbsp;&nbsp;&nbsp;&nbsp; anyOf = {
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {required = 
{"response_example"}},
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {required = 
{"response_schema"}}
&gt;&nbsp;&nbsp;&nbsp;&nbsp; }
&gt; }
&gt;
&gt;
&gt; phase 2, goal to implement higher-order ability,such as "expectation and
&gt; response patterns".
&gt;
&gt;
&gt;
&gt;

-- 
Thanks,
Janko

Reply via email to