@MaximillianLaumeister Where is "lunakid's link"?

There would seem to be an ambiguity in the question that is dividing people: Is the OP wanting to block access to the API itself if the user is outside the area (eg. using GeoIP), which seems to be implied by the question (in which case an alternative HTTP status code would be appropriate), OR are they determining that the user is outside the area only after a successful API call? From comments by the OP on the question it would seem to be the later, the API call itself is successful (200 OK), but the API has determined (from input) that they are requesting service in an unsupported area.

"advantage of themes, blog and hosting" - advantage over what? (A "dynamic" site can do just the same.)

Although, shouldn't it be "server", not "client" in most of these instances? It's the server that is processing the request and serving a response, the client just processes the response? In which case a 5xx code would be OK, since it's a server error, not a client error?

"You should only be giving a user an "error" if there is actually an error." - this. An empty results set when performing a "search" is not normally an "error". However, if the database connection failed that meant the search could not actually be performed then an empty results set (and no error) would otherwise be ambiguous. Some kind of error state would be appropriate in this case (perhaps together with an empty results set - depending on how the API is defined).

If you are worried that an "empty set might hide problems", could add a debug/logging mode to your library that would perhaps log such potential warnings?

"You can see that if some data element was passed as NULL the data would be interpolated as a database null in the database." - the linked SO question/accepted-answer does not appear to show this?

It's not just a "lack of variables" that's the problem with some of these answers (as already mentioned, there are no variables in stock CSS etc.), but the fact that many of these answers use a "magic number" without any explanation as to its meaning. In the accepted answer to the linked question, one of these values was questioned in comments and only then was an explanation given: "141% as 141 ~= √2 * 100 = the diagonal of the square". (But isn't this a SO meta question, rather than a Programmers question?)

"some statically typed OOP languages even have features to prevent it" - This isn't anything to do with a language being "statically typed". PHP, for instance, has the final keyword too, preventing class inheritance.

"Before HTML5, i and b were indeed deprecated." - The i and b elements have never been "deprecated". In HTML 4.01 they are both valid under a Strict DOCTYPE.

Readability (and debugging) should be a priority.

However, this is PHP, where type coercion is a "feature". If your function accepts arguments that "look like" integers (for example) that may be coming straight from a cookie, submitted (sanitized) form data, or some other serialized string data then failing on a strict data type might not be the way to go.

It depends. It depends what you are doing in your function and where the arguments are coming from. This is PHP - a "wrong" data type does not necessarily mean a wrong value. See my comment to Yannis answer. Take the "int" example... if it is wrong for your function to accept anything other than an int ie. you cannot continue in a meaningful way if something other than an int is passed then yes, throw an exception.