Is it correct to cover every parameter of JSON REST api with tests?

Question

Software testing

Short question:
There is a JSON API with 30 parameters. If you apply a per-field threshold + tests for the absence of each required field + 1 test for only required fields + 1 test for all fields at once, you get more than 100 tests.
1) Is it normal for manual testing? If not, what is the best way to limit it? Unfortunately, the choice here does not depend on me.
2) Is this normal for automated testing?
3) Did I miss something?
In detail with an example and a description of the tests:

Spoiler

Предусловие:
Что используется на сервере - неизвестно. Известен лишь формат и ограничения запроса/ответа.
К сожалению, тестированием API я раньше не занимался, по этому у меня есть 1 глобальный вопрос - "Что значит "достаточное" покрытие тестами JSON REST API запроса? Дальше я приведу пример запроса и попунктно свое видение тестов, не будет ли оно являться избыточным?"
Вопрос:
Необходимо обеспечить достаточное покрытие тестами.
Запрос (примерный, выдуманный, полей таких около 30:
{
"key1" : "String", // Длинна от 5 до 10 (обязательное поле)
"key2" : "String", // Длинна от 1 до 2
"key3" : "Array", // От 3 до 5 элементов, value:string от 2 до 4 (обязательное поле)
"key4" : "String", // Могут принимать значение лишь "CAR" и "MOTO"
"key5" : "boolean", // true или false (обязательное поле)
"key6" : "integer", // от 49 до 176 (обязательное поле)
"key7" : "Array" // длинна каждой строки от 3 до 10
}
Как я считаю необходимо протестировать:
Тест кейс 1: Полностью все поля присутствуют с корректными значениями;
Тест кейс 2: Только обязательные пол с корректными значениями;
Тест кейс 3-6: Отсутствие обязательных полей (по 1 тесту на каждое поле);
Тест кейс 7-10: Пограничное значение для key1;
Тест кейс 11-14: Пограничное значение для key2;
Тест кейс 15-18: Пограничное значение для key3;
Тест кейс 19-22: Пограничное значение для key3:value;
Тест кейс 23-26: Пограничное значение для key6;
Тест кейс 27-30: Пограничное значение для key7:string;
Тест кейс 31-33: Протестировать оба возможных и 1 невозможное значение;
Учитывая что полей в запросе около 30 - эти 33 кейса превратятся во все 100. Нормально ли это? Проблема в том, что на начальном этапе планируется ручное тестирование (не я принимаю такие решения и повлиять никак не могу).
Остальные вопросы:
1) На key7 количество элементов не ограничивается. Нормально ли это? Полагаю стоит сделать на это тесты в таком случае (еще 2, без элементов и большим их количеством);
2) Нужно ли тестировать каждое обязательное поле по отдельности?
3) Упустил ли я что то?

Answer 1

1) Is it normal for manual testing? If not, what is the best way to limit it? Unfortunately, the choice here does not depend on me.

All possible cases are not manually checked, usually limited only to critical cases (mandatory fields and boundary values ​​for the most important parameters are checked). It all depends on the requirements for testing and timing. If necessary, you can do all 100 tests manually.
Yes. In autotests, as a rule, all possible errors are checked.
Tests can be written endlessly, this again depends on the requirements of the customer and the timing. You can check for sending invalid JSON, sending requests with incorrect HTTP methods: GET, POST, HEAD, PATCH... etc.
You should not be limited to error checking scripts. Depending on different combinations of input parameters, different behavior can be implemented in the API. It is desirable to test all fundamentally different successful scenarios. For example, if the API has a boolean parameter, then you need to test the behavior when the value is true and the value is false.
Ideally yes. In practice, few people do this, especially with manual testing, especially if there are a lot of parameters. As a rule, a good API in the response always reports which of the required fields are not specified, list them and check in the responses. Three cases are checked: all required fields are not specified in the request, a couple of required fields are not specified, all required fields are specified in the request.

Answer 2

1. For each method, all regex expressions are prepared and checked for the correctness of the selection for the expected input data according to the "white" list (this applies not only to the API, but to everything):
parameter1 -> regex expression1
parameter2 -> regex expression2
etc.
2. These expressions are added to their methods, according to the correspondence table.
3. Each method is checked to ensure that the response with incorrect input data contains all the necessary information to understand what is happening.
4. Then 2-3 times run the entire process of the business logic with this API.
5. Everything is OK - you can "chat".

Answer 3

Writing more than 100 tests is not such a problem if the tests themselves are structured, such as making base / derived tests there, etc.
True, if you get carried away, you may need to test the tests themselves.