[jira] [Commented] (TUBEMQ-307) Introduce POST request support to WebAPI service

["Guocheng Zhang (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TUBEMQ-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200658#comment-17200658 ] 

Guocheng Zhang commented on TUBEMQ-307:
---------------------------------------

[~hystericalhell], What is the status of this issue, and are you still considering the part 3's implementation? I think it will be perfect if this part can be fully realized.

> Introduce POST request support to WebAPI service
> ------------------------------------------------
>
>                 Key: TUBEMQ-307
>                 URL: https://issues.apache.org/jira/browse/TUBEMQ-307
>             Project: Apache TubeMQ
>          Issue Type: Improvement
>          Components: Server
>            Reporter: Jeff Zhou
>            Assignee: Jeff Zhou
>            Priority: Major
>
> As for WebAPI service part, currently it supports only GET request, and supporting POST request could apparently and significantly improve the usability and extend the functionality of WebAPI itself.
> It could be described as below, some may be so familiar to developers, users, or relating stakeholders:
> 1. GET has hard limitation of the length of URL (2KB), however, POST using body to carry data section, so it does NOT have such limitation, e.g. you may request an API with even 16MB something if it's really needed;
> 2. GET requires data to be ASCII characters (or you have to encode them by BASE64 or something like it), however, POST body does NOT have such restriction, so you could literally post whatever kind of binary data you want, so it has wider compatibility, and reduces complexity and contributes to performance (no extra encoder needed);
> 3. GET combines all things in URL, so it could easily captured and cached, while it's visible and less secure to carry sensitive data like identity, however, POST is obviously safer as generally post body won't be cached or captured in analyzer or logger or something else in infrastructure;
> Provided TubeMQ is currently using Mortbay Jetty (Jetty 6, which has stopped maintenance for 10+ years), for security, performance and extensibility consideration, upgrade current Jetty component to Eclipse Jetty (Jetty 9, which is current mainstream of Jetty, now in hot developing) is an important requirement as well in addition to implementation of this functionality.
> Potential extra benefits from this upgrade:
> 1. HTTP 2 Support: maybe one day some of these features could play an important role of WebAPI interaction: Multiplexing / Server Push / Frame-based Compression / Stream Prioritization
> 2. Stay in latest distribution, with Feature and Security improvements (see Jetty VERSION: change log).
> So this improvement would consists of 3 major steps:
> 1. Upgrade Jetty 6 (mortbay) to Jetty 9 (eclipse), with NO WebAPI feature change;
> 2. Adding POST support to WebAPI, but stay in HTTP 1.1 as before;
> 3. Upgrade protocol to HTTP 2.0 for WebAPI (with backward compatibility to HTTP 1.1).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)