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. >
