Start as a consumer. Pick an API with genuinely good onboarding, sign up, get a key, and make a call with curl or Postman. Do it before you write a line of your own API. Ten minutes on the consuming side teaches you more about what makes an API good or bad than a week of reading about it, and it gives you a felt sense of the friction you are about to inflict on somebody else.
Then, when you build your own, resist the strongest gravitational pull in this business: exposing your database schema through HTTP and calling it an API. Design around what a consumer is trying to accomplish. Name things the way the business names them, not the way the ORM does.
Write the contract before you write the implementation if you can — an OpenAPI document you can mock and react to costs almost nothing to change, and a shipped API costs a great deal. If your team will not go design-first, that is fine and common; just make sure a machine-readable contract exists before anyone outside the team depends on it.
Finally, learn HTTP properly. Methods, status codes, headers, caching, content negotiation. A surprising share of bad API design is not bad taste — it is people reinventing, badly, something HTTP already does well.
