Не смогу с вами согласиться.
* Любая конструкция, заключённая в кавычки по-вашему является строкой. Мне кажется, подавляющее большинство ваших клиентов преобразует полученные пакеты в объектную модель, где ваши так называемые"строковые имена" становятся именами свойств. И бОльшая часть библиотек (com.google.gson, com.fasterxml.jackson, io.restassured, groovy.json.*) не согласны с подобным правилом именования.
* Учебник по JS (https://learn.javascript.ru/variables#variable-naming):
В JavaScript есть два ограничения, касающиеся имён переменных:
1. Имя переменной должно содержать только буквы, цифры или символы $ и _.
2. Первый символ не должен быть цифрой.
Мне не кажется логичным, чтобы разработчики "JavaScript Object Notation", действующие в контексте JavaScript, вдруг решили нарушить его ограничения.
* 24% ваших клиентов используют 1С (согласно результатам голосования в другой вашей теме). Разработчики платформы 1С, уверен, тоже исследовали этот вопрос и трактуют его аналогично приведённым выше библиотекам. При этом в 1С есть очень полезная фича - применение схем XSD к JSON-пакетам. Это действует примерно как JSON schema. Это сразу позволяет проверить валидность пакета, преобразовать св-ва к нужным типам и многое другое. Конечно, на старте обработки полученного JSON-пакета лучше сразу убедиться в его валидности, поэтому и производится попытка его приведения к типу объекта схемы XSD. Наличие нарушающих правила именования свойств при попытке преобразования к объектной модели даёт ошибку. ( Пакет.17302736.trips...)
Более того, приведённый пример вообще ставит крест на описании формата пакета в XSD за счёт динамических свойств (имена ТСок). Мы все понимаем, как не сложно можно было бы сделать их значениями, а не свойствами и возвращать массив. Тогда бы проблемы не было:
{
[
"unitID": "17296507", "trips": ...,
"unitID": "17301757", "trips": ... ,
"unitID": "17302736", "trips": ... ,
...
]
}
Пример для ответа на запрос "events/check_updates". Писал от руки, мог ошибиться.
Подскажите, у меня есть шансы быть услышанным?