Marton Greber has posted comments on this change. ( 
http://gerrit.cloudera.org:8080/23655 )

Change subject: Add Introducing REST API blog post
......................................................................


Patch Set 1:

(12 comments)

Thank you Gabi for putting this article together!
I've posted a couple observations, suggestions. Let me know what you think.

http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md
File _posts/2025-11-10-introducing-the-rest-api.md:

http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@3
PS1, Line 3: REST API to Apache Kudu
Not sure what was the final naming that we agreed on, but I think it would be 
important to outline that this API is for metadata management.
eg.: REST catalog; REST API for metadata management.


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@7
PS1, Line 7: high-performance
not sure if this is needed or just saying client applications is enough.


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@7
PS1, Line 7: REST API
REST API for metadata management


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@13
PS1, Line 13: The REST API in Apache Kudu provides a comprehensive HTTP 
interface for table metadata management operations. Built on top of Kudu's 
existing catalog management system, the API follows RESTful principles and 
returns JSON responses. This makes it easy to integrate Kudu with a wide range 
of applications and tools that can communicate over HTTP.
I think its not necessary to mention explicitly the json response part. I would 
outline that the main win is that for metadata operations one can omit a full 
client app and rather use rest. I would say:

The Apache Kudu REST API exposes table-metadata and administrative operations 
over HTTP on top of Kudu’s catalog. It lets users handle these tasks with 
lightweight REST calls instead of building a full client application.

What do you think?


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@21
PS1, Line 21: * **Leader-only Operations**: In multi-master setups, only the 
leader responds to requests
            : * **Leader Discovery**: Built-in endpoint to discover the current 
cluster leader
I would maybe say that remove these two bullet points from here. (In my opinion 
these fit more into the 'limitations' part)

Then maybe later rename the "Important Notes" section to "Limitations" and 
outline things there.


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@26
PS1, Line 26: `/api/v1/`
maybe mention that this is available on masters webserver on this path.


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@37
PS1, Line 37: ### Example Responses
IIUC these are now two responses. Without the request path/method it lacks 
context.

What do you think about adding a basic GET /api/v1/tables/<table_id> request
with the corresponding response here. Would that be more illustrative?


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@97
PS1, Line 97: For complete API documentation and examples, check out our 
Swagger UI:
            : ![png]({{ site.github.url }}/img/swagger.png){: .img-responsive}
While thinking about this I've figured that it would be nice to have the 
Swagger docs also on the Apache Kudu web site, for that I've filed: KUDU-3715

In the meantime in the article I think you can add a link to the raw api json:
https://github.com/apache/kudu/blob/master/www/swagger/kudu-api.json

And mention that on a Kudu cluster running this new feature the api docs are 
accessible on the webui. (If fancy you could add a screenshot)


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@100
PS1, Line 100: ## Important Notes
As mentioned above, I think a "Limitations" section would maybe be better here.


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@102
PS1, Line 102: ### Authentication
             : The REST API supports Kerberos/SPNEGO authentication, 
integrating seamlessly with Kudu's existing security mechanisms.
In case you go with the "Limitations" approach this could be removed from this 
section.


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@106
PS1, Line 106: In multi-master configurations, only the leader master will 
respond to REST API requests. Follower masters will return errors, so 
applications should use the leader discovery endpoint to find the correct 
master to connect to.
Maybe mention here that users can get the leader address by using the leader 
the /api/v1/leader endpoint.


http://gerrit.cloudera.org:8080/#/c/23655/1/_posts/2025-11-10-introducing-the-rest-api.md@111
PS1, Line 111: ## Configuration
Does it make sense to mention the webserver_enabled flag as well?



--
To view, visit http://gerrit.cloudera.org:8080/23655
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-Project: kudu
Gerrit-Branch: gh-pages
Gerrit-MessageType: comment
Gerrit-Change-Id: I1435431857a9f493e6492fae002c70f7af4cdd6c
Gerrit-Change-Number: 23655
Gerrit-PatchSet: 1
Gerrit-Owner: Gabriella Lotz <[email protected]>
Gerrit-Reviewer: Marton Greber <[email protected]>
Gerrit-Comment-Date: Tue, 11 Nov 2025 13:53:01 +0000
Gerrit-HasComments: Yes

Reply via email to