A well-designed API changes everything. It's the glue of your system — backend talks to frontend, to mobile, to third parties, all through the same beautiful, organized place. So enough with the small talk, let's get to the best practices that actually matter.
First: predictable URLs. If you have /users to list users, then /users/123 should return user 123. None of that /getUserById?id=123 — that's so 2010. Use plural for resources and keep it consistent. The dev consuming your API should be able to guess how it works without reading the docs (even though you have docs, of course).
Second: respect the HTTP verbs. GET is for fetching, POST is for creating, PUT/PATCH for updating, DELETE for deleting. Seems obvious, but there are APIs out there using POST for everything — even to delete resources. Don't do that to people. Your future self will thank you while debugging.
Third: versioning. Put it in the URL right away: /v1/users. Because believe me, you're going to change your API. Clients will complain. If you don't version, you'll either have to maintain legacy code forever or break everyone's app. Neither option is fun.
Fourth: authentication. These days, JWT with Bearer token in the Authorization header is the standard. Simple, it works, and any frontend knows how to handle it. Don't get fancy with tokens in the request body or URL — that's a security hole and a headache.
Bonus: proper status codes make a difference. 200 for success, 201 when you created something, 400 when the client messed up, 401 if not authenticated, 403 if no permission, and 500 if the error is on you. None of that returning 200 with {error: "something went wrong"} inside. That's just pure evil.
Bottom line: be predictable, use the right verbs, version from day one, and send the correct status codes. Your API doesn't need to be perfect — it just needs to not be a nightmare for others.