transport http-like api exceed the limit length

[jasonjoo2010]

Sentinel can be set rules through http protocol.

But all rules are transported to the api every time and would fail when the url exceeds the limit in RFC.(Bad Request will occur).

SO:

• Add more api(eg, addRule/removeRule)
• Put the data into post body

What do other guys think about?

[sczyh30]

Hi, the setRules API exposed from transport server is trivial and only used for demo dashboard. In production it's recommended to push the rules to remote config server from dashboard directly, rather than dashboard -> app -> remote config server. If you really need to push rules via HTTP API, you have to refactor for yourself (e.g. design RESTful APIs, split into different APIs, use standard HTTP methods GET/POST/PUT/DELETE) but we might not accept the changes. For Sentinel itself compatibility should be ensured.

[jasonjoo2010]

Hi, the setRules API exposed from transport server is trivial and only used for demo dashboard. In production it's recommended to push the rules to remote config server from dashboard directly, rather than dashboard -> app -> remote config server. If you really need to push rules via HTTP API, you have to refactor for yourself (e.g. design RESTful APIs, split into different APIs, use standard HTTP methods GET/POST/PUT/DELETE) but we might not accept the changes. For Sentinel itself compatibility should be ensured.

Thanks for response.

Some points i have questions:

1. Is dashboard production ready?
   The dashboard only does the basic things and we shall use it in production WITH or MUST WITH extending it. If it's ready for clusters which have less than 500 nodes like documents said maybe the answer is WITH?

2. Performance or usability which would be the reasons not production ready
   If the original dashboard is not production ready what are the main reasons, is that performance purpose or not fully functional or, it will give incorrect response(New rules will save only to dashboard-memory, but fail to sync)?

I think it's great giving some many methods to extend Sentinel* but we should give an out-of-the-box sentinel basically.

It's my opinion and Sentinel is a good guarder for various applications.

[sczyh30]

Sentinel itself is production-ready, but Sentinel dashboard is just for demonstrating the basic functionality of Sentinel. The rule config storage and metrics persistence vary in different production environment, so we are unlikely to provide all the solutions. All we can do is to provide the guideline on how to refactor the dashboard to adapt to your production environment. It may require some work, but it's not complicated.

[jasonjoo2010]

Sentinel itself is production-ready, but Sentinel dashboard is just for demonstrating the basic functionality of Sentinel. The rule config storage and metrics persistence vary in different production environment, so we are unlikely to provide all the solutions. All we can do is to provide the guideline on how to refactor the dashboard to adapt to your production environment. It may require some work, but it's not complicated.

I know your point and agree with it.
But all i said or my core point is that i treat it (rules in query string) is a kind of bug. Considering the compatibility and the system design maybe we can add support for post method.

Anyway, maybe patching it in private repository first is a better way now.

[sczyh30]

I know your point and agree with it.
But all i said or my core point is that i treat it (rules in query string) is a kind of bug. Considering the compatibility and the system design maybe we can add support for post method.

Anyway, maybe patching it in private repository first is a better way now.

I agree with you that entity in URL parameter is not a good design. Using POST method for this is better (and more standard), but regarding the API we have to consider about compatibility for old APIs after changes.

[jasonjoo2010]

I know your point and agree with it.
But all i said or my core point is that i treat it (rules in query string) is a kind of bug. Considering the compatibility and the system design maybe we can add support for post method.
Anyway, maybe patching it in private repository first is a better way now.

I agree with you that entity in URL parameter is not a good design. Using POST method for this is better (and more standard), but regarding the API we have to consider about compatibility for old APIs after changes.

yep, so I make a patch branch on our private mirror to make it correct with basically compatibility like:

       if (StringUtil.isEmpty(data) && request.getBody() != null && request.getBody().length > 0) {
            // for post data compatibility
            String body = new String(request.getBody());
            Map<String, String> map = parseData(body);
            data = map.get("data");
        }

Because the project is iterated fast we can lay it aside at this moment.

Thanks