Sure, its a good advice, how about "x-mock-by: apisix"?
------------------ ???????? ------------------
??????:
"dev"
<[email protected]>;
????????: 2022??1??9??(??????) ????5:57
??????: "dev"<[email protected]>;
????: Re: [Proposal] api mocking plugin: generate mock response for
debegging,testing or pressure measurement.
LGTM, Shall we add a Header to notify the client that the response is generated
by the mock plugin ?
Leslie Tsang
[email protected]
> On 6 Jan 2022, at 10:51 AM, EH <[email protected]> wrote:
>
> @shuaijinchao&nbsp;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&nbsp;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.
>
>
>
>
>
>
> ------------------&nbsp;????????&nbsp;------------------
>
??????:
"dev"
<[email protected] <mailto:[email protected]>&gt;;
> ????????:&nbsp;2022??1??5??(??????) ????7:09
> ??????:&nbsp;"dev"<[email protected]
<mailto:[email protected]>&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 <[email protected]&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
<https://github.com/nuysoft/Mock/wiki/Mock.Random&gt>; and kong's mocking
> &gt; plugin <https://docs.konghq.com/hub/kong-inc/mocking/&gt
<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
