How should I think before writing an API?
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.
Verify This Answer
Cross-check this information using these trusted sources:
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