Sound Good. Looking forward to this plugins. Leslie Tsang leslie.ts...@icloud.com
> On 10 Jan 2022, at 10:11 AM, EH <rui1...@foxmail.com> wrote: > > Sure, its a good advice, how about "x-mock-by: apisix"? > > > > > ------------------ 原始邮件 ------------------ > 发件人: > "dev" > > <leslie.ts...@icloud.com.INVALID <mailto:leslie.ts...@icloud.com.INVALID>>; > 发送时间: 2022年1月9日(星期天) 下午5:57 > 收件人: "dev"<dev@apisix.apache.org <mailto:dev@apisix.apache.org>>; > > 主题: 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 > leslie.ts...@icloud.com > > > On 6 Jan 2022, at 10:51 AM, EH <rui1...@foxmail.com> 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" > <shuaijinc...@apache.org <mailto:shuaijinc...@apache.org>&gt;; > > 发送时间:&nbsp;2022年1月5日(星期三) 晚上7:09 > > 收件人:&nbsp;"dev"<dev@apisix.apache.org > <mailto: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 > > <https://github.com/apache/apisix/blob/master/docs/zh/latest/plugins/fault-injection.md> > > > > EH <rui1...@foxmail.com <mailto: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 > <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
