API SDK Class Diagram
The code
classDiagram
class ApiClient {
-String baseUrl
-String apiKey
+get(path) Object
+post(path, body) Object
}
class BaseApi {
-ApiClient client
+send(method, path) Object
}
class UsersApi {
+list() List
+create(payload) Object
}
class InvoicesApi {
+list() List
+send(id) Object
}
BaseApi --> ApiClient
UsersApi --|> BaseApi
InvoicesApi --|> BaseApi
How this template works
Every SDK ends up with the same skeleton: one client that owns transport and credentials, a base class that wraps request plumbing, and a set of endpoint classes that add domain methods. This diagram documents that skeleton so contributors know where a new endpoint belongs before they write code. ApiClient holds the base URL and key privately, BaseApi delegates raw calls to it, and UsersApi and InvoicesApi inherit the plumbing while exposing only the operations their resource supports.
The syntax demonstrates both member styles and two relationship types. Inside ApiClient, the - prefix marks private members — -String baseUrl and -String apiKey — while +get(path) Object shows a public method with a parameter and a return type. The inheritance lines read from subclass to parent: UsersApi --|> BaseApi means UsersApi extends BaseApi, with the solid line and hollow triangle pointing at the class being extended. BaseApi --> ApiClient is a directed association showing that every endpoint class reaches the network through the shared client rather than duplicating it.
The gotcha is the direction of the inheritance arrow, which trips up people arriving from UML tools. In this syntax the child sits on the left and the parent on the right; writing BaseApi --|> UsersApi inverts the relationship and documents the opposite of what the code does. Method parameters with commas, as in +post(path, body) Object, are fine, but keep class names unique — a second block named UsersApi would merge into the first.
To adapt it, add a WebhooksApi class to show the pattern scaling, introduce a Config class holding timeouts and retries, or add an exception type associated with ApiClient to document error handling. The three-line relationship core stays stable as the SDK grows.
Related templates worth a look: the strategy pattern class diagram for interface-driven design, the domain model class diagram for the data these endpoints return, and the inheritance hierarchy class diagram for deeper subtype trees. The class diagram guide has the complete syntax reference.
Variations to try
- Add a WebhooksApi class to show the pattern scaling across a real SDK surface.
- Add an exception class and associate it with ApiClient to document error handling.
- Add a Config class holding timeouts and retries and associate it with ApiClient.
