Can an API not be an API?

Question

JavaScript

Hello.
I have a question in terms of the approach that my team leader uses and which makes me shake.
And now the doubt has arisen, maybe I'm wrong?

Closer to the point.
I'm a web developer, by the nature of my work I often have to make an AJAX request to get additional data. So, for me, all AJAX requests are APIs, and accordingly the response should be of this type:
{"code":1, "message":"username is required", "result":[....]}
where :
- code - response code. 0 - no errors, you can select data from the response and work with them; 1,2,3 - another error code, and the corresponding reaction.
- message - error description or success if everything is ok.
result - may be absent,

Teamlead says there is an API for external use and AJAX for internal consumption, where a strict response format is not needed. As a result, after receiving the answer

$.post("...", function(data_arr){
    if('error' in data_arr){
  ...
    }else{
        ...
    }
})

there is a banal check whether there is an error attribute and if so, the output. And if not, then everything is OK. And each such request of a different format gives answers (it is clear that more or less everything is the same, but still),

Hence the questions:
1. It is true that it is not always necessary to make an API for a small subrequest, and this is not an API, but just some kind of AJAX data loading ?
2. After all, it is correct to always use a single response standard, even if it is not a full-fledged API, but a trifle?

Answer 1

There is no vice police who will check your API and give you a deadline. Teamlead can do anything .
But for internal use it is not necessary to invent crutches . The format that the team leader suggested does not make life easier and does not look convenient.
PS The code parameter looks very strange, there are response codes - use it.

Answer 2

No, not "should", but can. Personally, I came up with this scheme:
- 200th status codes are sent ONLY when everything went well. In this case, there will be no success: true or response: {} - but the necessary data, right at the first nesting level. Actually, if we take it as a rule that the 200th codes are returned when everything is OK, then we can completely get rid of these bad checks for the presence of a key in the response.
- 400s and 500s will go into a separate callback/rejection promise, again eliminating the need to check any keys. For all response codes, except for 400 and 422 - there is no nichrome in the answer. No code, no message, no response. Nothing at all. All info is in the http status code itself. For 400 and 422, the code parameter is added, which is the number of the INTERNAL error (well, for example, there are some preconditions for executing the request - the uniqueness of the email address during registration as an example) - according to it, the front can show individual errors or perform some kind of logic.
In addition to all this, locally and on the server for the front, debugging is enabled, adding a certain _debug parameter to each response. Any info can be stored in it - an error message (even if it can be understood from the http code or internal), stack trace of the 500th error, and so on.

Answer 3

So, for me, all AJAX requests are API

This is your mistake. Ajax is far from API! Ajax is just an asynchronous request to the server. What's on the server is another matter.
Api can be pulled with both Ajax and curl and other methods.

Answer 4

The fact that the API will be used internally does not mean that there can be "mess". It would be correct to initially agree on the format that will be used in your team.
If there are no agreements, or disputes arise, there are some generally accepted standards:
See also OpenAPI , RAML , API Blueprint

Answer 5

just in the piggy bank https://habr.com/ru/post/441854/
(otherwise I will support the previous answer)

Answer 6

What you type will be your API. At least return the random fields.
What you cited as the team leader's argument looks so-so. API for "internal" use differs not in that it is not strict and you can make a mess there, but in that it is easier and faster to change it.
However, doing as the team leader says - returning {error: '...'} if there is an error, and {/*any data depending on the request*/} if everything is ok is a completely normal practice, and there is nothing wrong with that. the main thing is that the error field does not get caught in some kind of response, this is essentially your only limitation. Consider that you are using union types with a determinator based on the presence of the error field, if you want high formalities and calm down :)

Answer 7

An API in the broadest sense is just a way to access it from outside.
It can be absolutely anything. If only it was a way of access from the outside.