yanghua commented on issue #32: URL: https://github.com/apache/incubator-kyuubi/issues/32#issuecomment-895839930
> But based on statement resource will conflict with the overall design of kyuubi's backend service module and operation module, equivalent to HTTP API and Thrift API are two parallel solutions (this is a personal opinion) If we do not assume the users of these APIs, nor set limits on the scope of these APIs, can we just expose the capabilities of Kyuubi services as much as possible? Currently, our main focus is on matching capabilities equivalent to HS2 thrift rpc services. But Kyuubi's future ability should be a superset of this ability. For example, @turboFei wants to display Session/Operation logs. I understand that your point is to classify APIs according to potential user roles. On the other hand, it is also reasonable. But in what dimension do we classify? - Is the interface supported by thrift RPC service? - Is it session/operation related? Without classification, we will only need to follow RESTful principles, and our core focus is on resources. Regarding "authentication", we can take the non-HS2 interface API as a special case. In short, I personally have an open mind about whether to classify APIs. @pan3793 Can you chime in? > Of course, can this part be considered by kyuubi-ctl to replace the HTTP API implementation? IMO, it could be happened in the future. Even if kyuubi-ctl supports these capabilities, we still expect to release these capabilities through the http api so that we can build a visual UI for kyuubi. Some basic management APIs are still needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
