feat: As a user, I think the corresponding structure of the interception plug-in should be customized by the user.

[smileby]

Description

Description

The following plugin response structure is user defined

• limit-conn.lua
• limit-count.lua
• limit-req.lua
• uri-blocker.lua
• consumer-restriction.lua

Current State

return conf.rejected_code, { error_msg = conf.rejected_msg }

OR

return 401, { message = err_msg}

Desired State

return conf.rejected_code, conf.rejected_msg

OR

return 401, err_msg

[shreemaan-abhishek]

why?

[smileby]

After adjustment, it will be more flexible for users. Suppose I adjust it to:

return conf.rejected_code,  conf.rejected_msg

Users can customize the rejected_msg attribute

## url-blocker  config-1
{
  "_meta": {
    "disable": false
  },
  "block_rules": [
    "/*"
  ],
  "rejected_code": 200,
  "rejected_msg": "{\"error_msg\":\"reject access\"}"
}

## response-1
{"error_msg":"reject access"}

It can be like this

## url-blocker  config-2
{
  "_meta": {
    "disable": false
  },
  "block_rules": [
    "/*"
  ],
  "rejected_code": 200,
  "rejected_msg": "{\"code\":\"400\",\"desc\":\"block\"}"
}

## response-2
{"code":"400", "desc":"block"}

Because rejected_code is an http response code, in many scenarios, users may need a business type response code.

Many non-200 http response codes will cause business failure.

[Vacant2333]

After adjustment, it will be more flexible for users. Suppose I adjust it to:

return conf.rejected_code,  conf.rejected_msg

Users can customize the rejected_msg attribute

## url-blocker  config-1
{
  "_meta": {
    "disable": false
  },
  "block_rules": [
    "/*"
  ],
  "rejected_code": 200,
  "rejected_msg": "{\"error_msg\":\"reject access\"}"
}

## response-1
{"error_msg":"reject access"}

It can be like this

## url-blocker  config-2
{
  "_meta": {
    "disable": false
  },
  "block_rules": [
    "/*"
  ],
  "rejected_code": 200,
  "rejected_msg": "{\"code\":\"400\",\"desc\":\"block\"}"
}

## response-2
{"code":"400", "desc":"block"}

Because rejected_code is an http response code, in many scenarios, users may need a business type response code.

Many non-200 http response codes will cause business failure.

I think it's better for you to do this at the business level.

[smileby]

I understand that the plug-in function of apisix itself is part of the business.

For general api design, business response codes and corresponding response body structures may be needed to facilitate front-end processing.

I have looked at multiple plug-ins, and there is no unified standard for how they handle responses.

The content of rejected_msg mentioned before is customized by the user, so I think it will become more flexible.

I want to hear everyone’s thoughts on this feat.

[smileby]

Related: #8091

[Vacant2333]

@shreemaan-abhishek can u help take a look about this feat

[shreemaan-abhishek]

This looks like a fair enhancement to me but it might lead to breaking changes for users who already depend on the JSON nature of the response.

[smileby]

This looks like a fair enhancement to me but it might lead to breaking changes for users who already depend on the JSON nature of the response.

After the user upgrades, only the response body should be affected by the plug-in configuration. In theory, the response body will not cause disaster.

[Vacant2333]

This looks like a fair enhancement to me but it might lead to breaking changes for users who already depend on the JSON nature of the response.

After the user upgrades, only the response body should be affected by the plug-in configuration. In theory, the response body will not cause disaster.

looks like right, mostly users check the status code only i think

[smileby]

This looks like a fair enhancement to me but it might lead to breaking changes for users who already depend on the JSON nature of the response.

After the user upgrades, only the response body should be affected by the plug-in configuration. In theory, the response body will not cause disaster.

looks like right, mostly users check the status code only i think

agree