spacewander commented on issue #8091:
URL: https://github.com/apache/apisix/issues/8091#issuecomment-1891355327

   > Hi, @spacewander 😃 thank you for your reply.
   > 
   > What I want to express is the following:
   > 
   > For the limit-* plugins, the return structure is currently defined
   > 
   > ```
   >      return conf.rejected_code, { error_msg = conf.rejected_msg }
   > ```
   > 
   > Assume that the user plug-in configuration is as follows:
   > 
   > ```
   >      conf.rejected_code = 200,
   >      conf.rejected_msg = "Please try again later"
   > ```
   > 
   > When the corresponding rule is triggered, the request will return:
   > 
   > ```
   >      http code : 200
   >      reponse msg : {"error_msg": "Please try again later"}
   > ```
   > 
   > In most scenarios, the front-end logic requires the API to return a 
standard structure for processing, and they will expect to return customized 
data, such as:
   > 
   > ```
   >      http code : 200
   >      reponse msg : {"code": "0010", "desc": "Please try again later"}
   > ```
   > 
   > So, limit-* plugins should just return the error_msg without any wrapping. 
This is more convenient for most users. Even if _meta does what I'm saying.
   > 
   > If a user wants to return a JSON string, just let this user configure this 
JSON string. So the same for HTML or others.
   > 
   > In the documentation of each plug-in, there is almost no dedicated 
description of the _meta attribute. Users may need to consult more information 
to deal with this issue.
   > 
   > So I think it would be most convenient to adjust the return structure of 
the plug-in.
   > 
   > I want to hear your thoughts 😊 ~~~
   
   I see. Thanks for your explanation! The thing I worry about is that the 
change in returning messages will be a break change. That is part of the reason 
that we introduced `error_response`.
   
   Let's wait for the current maintainer to decide if the break change is 
worthwhile.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to