The answer
Start with what the user is trying to do. Then define input, output, status codes, edge cases, database needs, side effects, permissions, and validation. Write a short LLD doc. Then code from the doc.
How to Think Before Writing an API
How should I think before writing an API?
More FAQs in How to Think Before Writing an API
Because the API serves the user. If you cannot say what the user is trying to do, you do not understand the feature. Starting with the user anchors every other decision (input, output, edge cases).
Resource does not exist (404), user not authenticated (401), user not authorized (403), input invalid (400), duplicate (409), and server error (500). For each, decide what the API should do.
Emails, counter updates, event emissions, notifications. For each, decide if it is sync (in the request) or async (in a queue). Sync side effects slow the request; async ones do not.
Still have questions?
Browse all our FAQs or reach out to our support team
Want to upskill yourself?
Your learning library
Small steps. Big possibilities.
Find your next course. Build something great.