On Thu, Apr 23, 2020 at 3:38 PM jie123108 <[email protected]> wrote: > >```` > >{error_msg: 'error message’} > >```` > > >I think this style should be enough. >The `code` is meaningless, I do > not like it. >The `code` is meaningless too. >most of case: >{ok = true} > >{ok = false, error_msg = "xxxx"} >so we can drop `ok`, it is meaningless. > > What I'm trying to say is that if the business system is developed and > online. The data format it defines is > ``` > {ok:false, errmsg:'error message'} > ``` > And the client also does this logically. > Thus, after using apisix processing, some error scenarios return > ``` > {error_msg: 'error message’} > ``` >
I got your mind. We can implement this feature by a plugin. Set a flag to `ctx` when APISIX tries to return error message. Rewrite the response body to the new format at `body_filter` phase. > > > For the client, this is the wrong message format. The client expects it to > be in the format given above. > Shouldn't the gateway be able to adapt to different message formats? > > > My example is json. What if the business system is not using json? > For example, if you use msgpack format, then you can easily adapt the > message to msgpack format with response_format. -- *MembPhis* My github: https://github.com/membphis Apache APISIX: https://github.com/apache/incubator-apisix
