Почему collection+json использует анонимные объекты вместо пар ключ-значение
Я пытаюсь найти схему данных, которую можно использовать для разных сценариев, и многообещающим форматом, который я до сих пор нашел, является формат collection+json ( http://amundsen.com/media-types/collection/).
До сих пор он обладает многими необходимыми мне функциями и очень гибок, однако я не понимаю, почему он использует анонимные объекты (пример: {"name" : "full-name", "value" : "J. Doe", "prompt" : "Full Name"},) вместо простых пар ключ-значение. (пример: "ФИО": "Дж. Доу",).
Я вижу, как вы можете передавать больше информации, такой как приглашение и т. Д., Но синтаксический анализ выполняется намного медленнее, и для него сложнее создать клиент, поскольку он должен обращаться к полям путем поиска в массиве. При привязке данных к конкретному представлению необходимо знать, какие поля существуют, поэтому анонимные объекты необходимо снова преобразовать в карту значений ключей.
Так есть ли реальное преимущество в использовании этого анонимного объекта вместо карты значения ключа?
2 ответа
Я написал этот вопрос и затем забыл об этом, но нашел ответ, который искал здесь:
От Майка Амундсена, создателя коллекции +JSON
Я понимаю ваше желание добавить шаблоны сериализации объектов в CJ. Однако одна из основных целей моего CJ-дизайна - не поддерживать сериализацию объектов. Я знаю, что сериализация является часто запрашиваемой функцией для веб-сообщений. Это отличный способ оптимизировать как код, так и опыт программиста. Но это не то, к чему я стремлюсь в этом конкретном проекте.
Я думаю, что расширение Kevin ref'd является хорошим вариантом. Не уверен, что кто-то действительно использует это, хотя. Если вы хотите создать его (основываясь на вашей идее "тела"), это круто. Если вы хотите начать без ссоры вместо того, чтобы делать все "тянуть", это круто. Отправьте это и давайте поговорим об этом.
С другой стороны, я написал очень простой синтаксический анализатор на стороне клиента для CJ (он находится в основной папке репо), чтобы показать, как скрыть "дорогостоящие" части навигации по модели состояния CJ. На самом деле у меня есть рабочий элемент для создания клиентской библиотеки, которая может преобразовать представление состояния в произвольную локальную объектную модель, но у меня еще не было времени выполнить работу. Может быть, это то, что вы хотели бы помочь мне с?
На более глубоком (и, возможно, более скучном) уровне этот подход к модели состояний является частью более широкой модели, которую я имею в виду, чтобы рассматривать сообщения как контейнеры "без типа" и позволять клиентам и серверам использовать любые локальные объектные модели, которые они предпочитают. - без необходимости межсетевого соглашения по этой объектной модели. Это "модель самоуверенного дизайна", над которой я работаю.
Наконец, как вы правильно заметили в верхней части потока, HAL и Siren гораздо лучше поддерживают сообщения в стиле сериализации объектов. Я думаю, что это очень круто, и я призываю людей (включая моих клиентов) использовать эти другие форматы, когда сериализация объектов является предпочтительным шаблоном, и использовать CJ, когда передача состояний является предпочтительным шаблоном.
Я думаю, что основная причина в том, что клиент-потребитель не должен заранее знать формат данных.
Как теперь предлагается в collection+json, вы знаете, что в объекте данных вы найдете информацию о данных, просто проанализировав их, "имя" всегда является идентифицирующим именем поля, "значение" является значением и т. Д. Ваш клиент может не знать, сколько полей или их имен:
{
"name" : "full-name",
"value" : "J. Doe",
"prompt" : "Full Name"
},
{
"name" : "age",
"value" : "42",
"prompt" : "Age"
}
если бы вы имели вместо
{
"full-name" : "J. Doe",
"age" : "42"
}
клиент должен иметь предварительные знания о вашем представлении, поэтому он должен ожидать и понимать "полное имя", "возраст" и все специфичные для приложения поля.