Hi Community, Any ideas on this?
Best Regards! @ Zhiyuan Ju <https://github.com/juzhiyuan> EH <rui1...@foxmail.com> 于2022年1月6日周四 10:52写道： > @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>; > 发送时间: 2022年1月5日(星期三) 晚上7:09 > 收件人: "dev"<dev@apisix.apache.org>; > > 主题: 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> 于2021年12月31日周五 15:43写道： > > > *Background* > > usualy when we develop a new feature on website or miniprogram or > mobile > > application, we go through 3 steps: > > 1. design api documents,include api path,paramter,response; > > 2. develop frontend and backend at the same time; > > 3. testing and debugging the frontend and backend program. > > > > in step 2, the frontend need to mock the api’s parameter and > response,to > > debug program,and if there’s multiple front-end applications,each app > need > > to do mock. > > > > consider this scenario,if our api gateway can support api mocking,the > > steps 2 will come down to: > > 1. turn on mocking plugin when backend is still developing apis. > > 2. turn off mocking plugin when the api is finished. > > and there is nothing need to do for frontend developer,even neednt to > > change the api url. > > > > based on the above scenario, the mocking plugin can be use in more > > scenario,such as: > > > > - when we pressure test the APISIX. we can use the > mocking plugins to > > mock duration of api and status and > response,instead of real upstream. > > - in microservice invocation chain,we can mock > service one by one to > > find the abnormal service. > > > > *Plugin Design* > > this plugin design is reference to mock.js > > <https://github.com/nuysoft/Mock/wiki/Mock.Random> and kong's > mocking > > plugin <https://docs.konghq.com/hub/kong-inc/mocking/>. > > it is planned to be implemented in two phases. > > > > phase 1, goal to implement base mock abilities. > > the general design is as follows: > > > > local schema = { > > type = "object", > > properties = { > > -- specify response > delay time,default 0ms > > delay = { type = > "integer" }, > > -- specify response > status,default 200 > > response_status = { > type = "integer" }, > > -- specify response > content type,support application/xml,text/plain and > application/json,default application/json > > content_type = { type > = "content_type" }, > > -- specify response > body. > > response_example = > {type = "string"}, > > -- specify response > json schema,if response_example is not nil,this conf will be ignore. > > -- generate random > response by json schema. > > response_schema = { > type = "object" }, > > }, > > anyOf = { > > {required = > {"response_example"}}, > > {required = > {"response_schema"}} > > } > > } > > > > > > phase 2, goal to implement higher-order ability,such as "expectation > and > > response patterns". > > > > > > > > > > -- > Thanks, > Janko
