API Design on Prateek Sharma

Give callers two error types, one extending the other

Fri, 28 Aug 2026 00:00:00 +0000

In the WazirX Java connector I split errors into two:

WazirxClientException — the caller made a mistake the caller can fix: a bad side value, a missing required field. Thrown before a request is even sent.
WazirxApiException — something went wrong once the request left the process: a network failure, a non-2xx response.

WazirxClientException extends WazirxApiException. That one line is the whole design. A caller who only cares “did this work?” catches the parent. A caller who wants to retry network failures but fail fast on their own bad input catches both separately. Nobody is forced into a giant catch (Exception e) that swallows bugs, and nobody has to try/catch five specific types at every call site.

Generic returns can be the right call for a library you maintain alone

Wed, 26 Aug 2026 00:00:00 +0000

The standard advice for a client library is: give callers typed responses. client.Ticker(...) (*Ticker, error), not (any, error). I went the other way in my WazirX Go connector and I still think it was right for that library.

The upstream API’s response shapes move around — objects that become arrays, fields that appear and vanish across endpoints. With ~25 endpoints and one maintainer (me, in spare hours), typed structs would mean 25 things to keep in sync with an API I don’t control and can’t see changes to until they ship. The generic return pushed that cost to the call site, where the caller already knows which two fields they want and can assert for them.

Endpoint maps over hand-rolled methods

Tue, 25 Aug 2026 00:00:00 +0000

I’ve now written two client libraries for the same exchange API — one in Go , one in Java — and the thing I’d keep from both is the same: don’t write a method per endpoint. Describe the endpoints as data and dispatch through one function.

The shape of the problem

The API has roughly two dozen endpoints. They differ in four ways:

HTTP verb (GET, POST, DELETE)
path
whether the request must be signed
the response body

Everything else — building query params, adding a signature, choosing the verb handler, parsing the response — is identical. Writing a hand-rolled method per endpoint means writing that identical body 25 times, and then maintaining 25 copies of it when the signing scheme or the base URL handling changes.

WazirX Go Connector

Sun, 23 Aug 2026 00:00:00 +0000

WazirX is one of India’s largest crypto exchanges, and while its REST API is well documented, it doesn’t ship an official Go client. I wanted to poke at their API for a side project and didn’t want to hand-roll request signing and endpoint plumbing every time, so I built wazirx-connector-go and open-sourced it once it was in decent shape.

Avoiding ~25 near-identical methods

The exchange exposes close to two dozen endpoints — tickers, order book depth, order placement, withdrawals, sub-account transfers, and so on. Writing a hand-rolled method for each one would have meant the same boilerplate repeated two dozen times: build params, sign if needed, pick GET/POST/DELETE, hit the URL, parse the response.