ออกแบบ API สาธารณะขนาดเล็ก

Your module's public API is the set of functions and types other code is allowed to call. It is the front door both apps walk through.

A small surface area means fewer things to learn and fewer things to break. Expose only what callers truly need, nothing more. 🎯

Design backwards: write the call site you wish you had first. Let that ideal usage shape what your public functions look like.

A good API shows the intent and hides the steps. Callers say what they want, not how the work gets done inside.

Clear names are half your API. A method called priceWithTax tells the whole story without any extra docs to read.

Take plain, obvious inputs like strings and numbers. Simple parameters make your API easy to call from both Android and iOS.

Return shared data classes instead of loose values. A typed result is self-describing and far harder to misuse.

Internal helpers and rough edges should stay private. Only the entry points a caller actually uses belong in the public API.

Every public thing is a promise. It is easy to add new API later, but removing it can break callers, so expose less up front.

Keep the API platform-neutral. If a signature mentions Android or iOS types, it cannot serve both apps from shared code.

The best APIs read like a sentence at the call site. Optimize for the caller, not for whoever wrote the implementation.

Let's test your API design instincts.

A great public API is small, clearly named, and shaped by real use cases. Expose intent, hide steps, and both teams will love it. 🎉