What an API actually is

An API is a contract. Something asks for a resource and gets a predictable response, and the value is that both sides can be built separately and changed independently.

REST is a set of conventions, not a standard, and following them makes your API predictable to anybody who has used another one.

Resources are nouns, not verbs. A path for users, a path for orders. Not a path called getUserData, because the method already says what you are doing.

The methods carry the meaning. GET retrieves and changes nothing. POST creates. PUT replaces. PATCH updates part. DELETE removes.

GET must not change anything, which is the rule most commonly broken and which causes real problems, because anything may retry a GET: a browser, a proxy, a link preview.

Status codes should be used properly. 200 for success, 201 for created, 400 for a bad request, 401 for not authenticated, 403 for not allowed, 404 for not found, 422 for validation failure, 500 for your own error. An API returning 200 with an error message in the body is a common and unhelpful pattern, because every client then has to parse the body to find out whether it worked.

Be consistent in naming, in structure and in error format across every endpoint, because a client writing against your API learns the pattern once and then expects it everywhere.

Design the endpoints before writing code, because changing an API after clients depend on it is expensive.