[
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)
