Thanks for driving this FIP. +1 (non-binding) Best regards, Zhe Wang
Leonard Xu <[email protected]> 于2026年8月10日周一 17:56写道： > Thanks Junbo for driving this FIP. > > +1 (binding). > > Best, > Leonard > > > 2026 8月 9 11:15 上午，Junbo Wang <[email protected]> 写道： > > > > Hi Jark and all, > > > > Thanks a lot for the careful review — all three points make sense to me, > and I’ve updated the FIP [1] to address them: the lookup paths are > simplified, the supported operations per table type are documented together > with the error behavior, and the Authorization header, including Bearer > tokens, is now covered in the authentication section. > > > > As these feel more like clarifications than changes to the design under > vote, I’d suggest keeping the current vote open, with the 72 hours counted > from this update. That said, if any of them turns out to need more > discussion, I'm happy to bring it back to the DISCUSS thread [2] and start > a fresh vote afterwards. > > > > Looking forward to further feedback. > > > > [1] > https://cwiki.apache.org/confluence/spaces/FLUSS/pages/444334561/FIP-49+Fluss+Gateway+REST+API > > [2] https://lists.apache.org/thread/s5yjysvoj8o6nxdj49m99hg8yn51tgjw > > > > > > > > Best regards, > > Junbo Wang > > > >> On 9 Aug 2026, at 09:45, Junbo Wang <[email protected]> wrote: > >> > >> Hi Keith, > >> > >> Thanks for the reminder. This should already be a separate [VOTE] > thread [1] — the mail was sent as a new email rather than a reply to the > [DISCUSS] thread [2], and > >> its In-Reply-To/References headers are empty on the archive. Your mail > client may have grouped it under the discussion because of the similar > subject. > >> > >> Please let me know whether it still looks off on your side. > >> > >> [1] https://lists.apache.org/thread/t5jkcvo8b07oxjywbckotbsxl8fhcd76 > >> [2] https://lists.apache.org/thread/s5yjysvoj8o6nxdj49m99hg8yn51tgjw > >> > >> > >> Best regards, > >> Junbo Wang > >> > >>> On 8 Aug 2026, at 19:06, Jark Wu <[email protected]> wrote: > >>> > >>> 1. Could we remove the extra "records" segment from the lookup paths? > >>> > >>> Point Lookup: > >>> POST /v1/clusters/{cluster}/databases/{database}/tables/{table}/lookup > >>> > >>> Prefix Lookup: > >>> POST > /v1/clusters/{cluster}/databases/{database}/tables/{table}/prefix-lookup > >>> > >>> 2. The /records write API does not explicitly define its supported > >>> operation types. My understanding is that Log tables support "append" > >>> only, while primary-key/KV tables support "upsert" and "delete". Could > >>> we document this operation/table compatibility and the error behavior > >>> for unsupported combinations? > >>> > >>> 3. Could we explicitly support and document the HTTP Authorization > >>> header, especially Authorization: Bearer <token>? This is a common > >>> authentication mechanism for cloud services: Databricks Zerobus and > >>> Confluent REST Proxy use OAuth/OIDC bearer tokens, while Alibaba Cloud > >>> OSS carries signed credentials in the Authorization header [1][2][3]. > >>> The Gateway can validate the credential, resolve it to a principal, > >>> and propagate that principal through the existing identity/act-as > >>> mechanism. > >> > > > >
