что такое json server
JSON-server. Тестируем front-end без back-end
В последние время по вечерам частенько играюсь с JavaScript и фреймворком angular.js. Сидишь себе, что-нибудь изобретаешь, и постоянно упираешься в одну и ту же проблему – чтобы нормально потестить новоиспеченное приложение необходимо принимать какие-нибудь данные с сервера.
Например, хочется мне сделать телефонный справочник. Не проблема, накидываю структуру, пишу JS и все бы хорошо, но ведь в реале телефоны должны храниться на сервере. Пока сервера нет – создаю заглушки, но это удобно далеко не всегда. Как было бы хорошо иметь какую-нибудь тулзу, которой можно скормить файл в json формате и получить готовое API для проведения тестов.
Json-сервер. Строим велосипед
Сначала мне было лень что-то искать, и я решил проблему по-нашему, по-программерски. Написал небольшой скриптик, который отдавал подготовленный набор данных в формате json. Все дешево и сердито. Вроде данные возвращает, но нет возможности генерировать нормальную структуру пути (например, users/1/comments). Вдоволь поигравшись со своим велосипедом и получив ломку в виде «мне не хватает гибкости», мне пришлось выбросить свое творение и отправиться на GiHub в поиске чего-то более продвинутого.
Json-server – решение всех моих проблем
Поиск по ключевым словам “json server” сразу вывел меня на проект «json-server». На момент поиска проект насчитывал больше 7000 звездочек, а это один из признаков качества и популярности решения. Бегло прочитав описание, понял, что это то что мне и нужно, даже больше.
JSON-server позволяет решить сразу несколько проблем:
Скармливаем подготовленный файл json-server и сразу получаем поднятый web-сервер с готовым API: http://localhost:3000/posts/1. Поскольку определенный функционал повторяется от проекта к проекту, я сразу себе сделал несколько заготовок и теперь постоянно их использую.
Простой пример динамического формирования данных:
Пример использования json-server
Я понимаю, что все примеры можно посмотреть в документации, но раз уж взялся за описание, то приведу сразу небольшой рабочий кейс.
Содержимое файла data.json:
Берем на заметку
Посмотреть полную документацию и внести при желании свою лепту в развитие проекта всегда можно через репозиторий на git hub.
Русские Блоги
Использование JSON Server в процессе быстрой разработки
В процессе разработки интерфейс чаще всего отстает от разработки страницы. Используйте JSON Server, чтобы быстро создать симуляцию, чтобы вернуть фоновые данные в стиле REST, чтобы обеспечить разделение внешней и внутренней разработки. Для интерфейсной и внутренней разработки, если заданы интерфейс и определение данных, остальное можно разработать отдельно и, наконец, интегрировать тестирование.
JSON Server как инструмент, разработанный на базе Express, достаточно простой для записи небольшого количества данных, вы можете его использовать, поддерживает междоменные запросы CORS и JSONP, поддерживает методы GET, POST, PUT, PATCH и DELETE, и предоставляет ряд методов запроса, таких как limit, order и т. д.
установка
запускать
Создайте сервер каталогов и создайте файл json в каталоге db.json.
Выполнить в каталоге сервера
Поддерживаемые методы
По API http://localhost:3003/list Например
Расширенный поиск
Filter
Paginate
Использовать _sort с участием _order (По умолчанию по возрастанию)
Для сортировки по нескольким полям вы можете использовать следующий формат:
Slice
использовать _start с участием _end или же _limit (Пользовательский заголовок X-Total-Count находится в ответе), как и метод среза данных.
Operators
использовать _gte или же _lte Чтобы получить диапазон.
использовать _ne Чтобы исключить значение
Используйте _like для фильтрации (поддержка RegExp)
search
Relationships
Свяжите дочерние ресурсы, добавьте _embed
Включить родительский ресурс, добавить _expand
Для получения или создания вложенных ресурсов (один по умолчанию, многоуровневый, настраиваемые маршруты)
Database
Homepage
Развернуть функцию
Статический файловый сервер
Изменить номер порта
Доступ из любого места
Вы можете использовать CORS и JSONP для доступа к своему API из любого места.
Удаленный файл
Вы можете загружать удаленные файлы
Генерировать случайные данные
Используйте файл js вместо файла json для динамического создания данных. Его также можно сгенерировать с помощью других модулей, таких как Faker, Casual, Chance или JSON Schema Faker.
HTTPS
Пользовательская маршрутизация
Создайте файл routes.json. Обратите внимание, что каждый файл маршрутизации должен начинаться с / начало.
Теперь вы можете использовать дополнительные маршруты для доступа к ресурсам.
Добавить промежуточное ПО
CLI usage
Вы можете выставить настройки в json-server.json В конфигурационном файле.
Использовать json-сервер как модуль
В проекте, если вам нужно добавить аутентификацию, проверку или другие функции, вы можете использовать json-сервер в качестве модуля и объединить другое промежуточное ПО Express.
Простой пример
Вы предоставляете jsonServer.router Путь метода относительно вашего узла.
Если вы запустите приведенный выше код с другого пути, лучше всего использовать абсолютный путь.
Пример динамических данных настраиваемой маршрутизации
Добавить маршрут к выходным параметрам запроса
Добавить отметку времени
Требуется поддержка почтового запроса bodyParser
Русские Блоги
json-сервер подробно
Установить json-сервер
Запустить json-сервер
json-server Вы можете напрямую разместить файл json на веб-сервере с полным API в стиле RESTful и поддерживать междоменный, jsonp, настройку маршрутизации, сохранение снимков данных и другие функции.
Содержимое файла db.json:
Например, следующая команда разместит файл db.json как веб-службу.
Результат аналогичен следующему, что указывает на успешный запуск.
На этом этапе вы можете открыть свой браузер и ввести:http://localhost:53000/course
параметры запуска, связанные с json-сервером
Динамически генерировать данные моделирования
App.js с библиотекой mockjs может легко генерировать данные моделирования.
маршрутизация
Маршрут по умолчанию
json-server предоставляет API для запросов GET, POST, PUT, PATCH, DELETE и других, соответствующих всем типам сущностей в данных, соответственно.
Пользовательская маршрутизация
Конечно, вы можете настроить маршрутизацию:
Пользовательский профиль
Настройка маршрутизации, файлов данных, мониторинга и т. Д. Через командную строку сделает команды очень длинными и легко допускающими ошибки. Вы можете записать команды в сценарии npm, но конфигурация все равно неудобна.
json-server позволяет нам поместить всю конфигурацию в файл конфигурации, по умолчанию это файл конфигурации json-server.json;
Используйте файл конфигурации для запуска json-сервера:
Фильтровать запрос
Данные запроса могут предоставить дополнительные
Вы также можете использовать некоторые условия оценки в качестве помощи для фильтрации запросов.
Доступные условия сварки:
Запрос на пейджинг
Параметры разбивки на страницы по умолчанию: _page количество страниц, _limit количество страниц на странице.
По умолчанию на каждой странице есть 10 записей.
Фон вернет общее количество элементов, а общее количество данных будет в заголовке ответа: X-Total-Count.
Сортировать
Поддержка сортировки по нескольким полям:
Произвольные данные среза
Полнотекстовый поиск
в состоянии пройти q Параметры для полнотекстового поиска, например: GET /posts?q=internet
Ассоциация сущностей
Связанная плодоносящая сущность
содержит дочерние объекты, добавьте _embed
Связанная родительская сущность
содержит родительский объект, добавьте _expand
Другое расширенное использование
json-server Он разработан с использованием экспресс-доставки и может быть глубоко адаптирован. Детали не будут расширяться, пожалуйста, обратитесь к официальному сайту для уточнения деталей.
Создание фейкового REST API с помощью json-server-а
В этом уроке, с помощью json-server-а вы научитесь создавать и взаимодействовать с фейковым REST API, который будет полезен при разработке как мобильных, так и веб приложений. Данный урок предполагает, что у вас есть базовые знания о работе с форматом JSON и HTTP запросами.
Что такое REST?
REST — это сокращение от англ. Representational State Transfer (передача состояния представления). Это архитектурный стиль взаимодействия компонентов распределённых приложений. Он предназначен для взаимодействия множества устройств путём выполнения простых HTTP запросов. В результате этого пользовательские данные актуализируются не за счёт простого обращения к URL, а за счёт отправки разных видов HTTP запросов, таких как: GET, POST, DELETE и т.д. для достижения определённых целей.
Зачем нам нужен фейковый REST API?
REST API может являться бэк-энд стороной любого мобильного или веб приложения. Зачастую во время разработки, REST API попросту не готов. Чтобы увидеть мобильное или веб приложений в действии вам потребуется сервер, которые будет возвращать случайные данные в формате JSON.
Вот тут-то нам и пригодится фейковый REST API. Инструмент json-server обладает набором нужного функционала, чтобы вы смогли без особых усилий настроить фейковый REST API сервер.
Начало работы
Чтобы начать работу с json-server вам потребуется его установить через Менеджер пакетов Node (npm).
Создайте JSON файл в котором приведите пример требуемого формата возвращаемых данных. К примеру, мне потребуется JSON данные о пользователе: идентификатор, имя, расположение и т.д.. Я создам файл info.json со следующим JSON кодом:
Запускаем сервер через командную строку, указывая файл info.json в качестве источника данных REST API, доступных по адресу http://localhost:3000.
Тестирование точек входа REST API
Теперь когда фейковый REST API сервер запущен давайте посмотрим как осуществить запрос, используя HTTP клиент. Для создания запросов к API я воспользуюсь инструментом Postman.
Запросы типа GET
Запросы типа POST
Для того чтобы добавить новые данные к уже существующим необходимо совершить POST запрос к URL http://localhost:3000/users. POST запрос должен выглядеть следующим образом:
Запросы типа DELETE
Запрос типа PATCH
Для того чтобы обновить уже существующую запись необходимо отправить PATCH запрос с указанием новых значений для уже существующей записи. К примеру, чтобы обновить пользователя с Id 2, отправьте PATCH запрос по адресу http://localhost:3000/users/2:
Организация поиска в json-server REST API
json-server REST API позволяет вам осуществить поиск данных, по определённым критериям. К примеру, чтобы найти всех пользователей по имени необходимо отправить GET запрос к REST API URL как это показано ниже:
Работа с постраничным разбиением результатов
В результате выполнения GET запроса представленного выше, будет выведен список из пяти пользователей со второй страницы. Изменение параметра _page позволит нам получить данные с нужной страницы.
Сортировка результата
Работа с операторами
Вдобавок ко всему выше сказанному, json-server поддерживает работу с операторами, с помощью которых можно осуществить поиск по Id в определённом диапазоне или по регулярному выражению.
Заключение
В этом уроке мы рассмотрели основы работы с json-server REST API для создания тестовой базы данных. Вы научились устанавливать json-server и взаимодействовать с URL для добавления, обновления, изменения и удаления данных. Также вы увидели как осуществить поиск по записям, используя операторы и регулярные выражения.
Что такое JSON
Если вы тестируете API, то должны знать про два основных формата передачи данных:
XML — используется в SOAP (всегда) и REST-запросах (реже);
JSON — используется в REST-запросах.
Сегодня я расскажу вам про JSON. И расскажу в основном с точки зрения «послать запрос в Postman или прочитать ответ», потому что статья рассчитана на студентов, впервые работающих с Postman.
JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.
JSON используется в REST API. По крайней мере, тестировщик скорее всего столкнется с ним именно там.
Что такое API — общее знакомство с API
Что такое XML — второй популярный формат
В SOAP API возможен только формат XML, а вот REST API поддерживает как XML, так и JSON. Разработчики предпочитают JSON — он легче читается человеком и меньше весит. Так что давайте разберемся, как он выглядит, как его читать, и как ломать!
Содержание
Как устроен JSON
В качестве значений в JSON могут быть использованы:
Число (целое или вещественное)
Литералы true (логическое значение «истина»), false (логическое значение «ложь») и null
Я думаю, с простыми значениями вопросов не возникнет, поэтому разберем массивы и объекты. Ведь если говорить про REST API, то обычно вы будете отправлять / получать именно json-объекты.
JSON-объект
Как устроен
И разберемся, что означает эта запись.
Объект заключен в фигурные скобки <>
JSON-объект — это неупорядоченное множество пар «ключ:значение».
Ключ — это название параметра, который мы передаем серверу. Он служит маркером для принимающей запрос системы: «смотри, здесь у меня значение такого-то параметра!». А иначе как система поймет, где что? Ей нужна подсказка!
Вот, например, «Виктор Иван» — это что? Ищем описание параметра «query» в документации — ага, да это же запрос для подсказок!
Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):
Когда пользователь начинает вводить данные в формочку, то сразу видит результат — появляется список подсказок. Это значит, что разработчик прописал в коде условие — делать некое действие на каждый ввод символа в это поле. Какое действие? Можно увидеть через f12.
Открываем вкладку Network, вбиваем «Виктор Иван» и находим запрос, который при этом уходит на сервер. Ого, да это тот самый пример, что мы разбираем!
Клиент передает серверу запрос в JSON-формате. Внутри два параметра, две пары «ключ-значение»:
query — строка, по которой ищем (то, что пользователь вбил в GUI);
count — количество подсказок в ответе (в Дадате этот параметр зашит в форму, всегда возвращается 7 подсказок. Но если дергать подсказки напрямую, значение можно менять!)
Пары «ключ-значение» разделены запятыми:
Строки берем в кавычки, числа нет:
Конечно, внутри может быть не только строка или число. Это может быть и другой объект! Или массив. Или объект в массиве, массив в объекте. Любое количество уровней вложенности =))
Объект, массив, число, булево значение (true / false) — если у нас НЕ строка, кавычки не нужны. Но в любом случае это будет значение какого-то ключа:
Переносы строк делать необязательно. Вообще пробелы и переносы строк нужны только человеку для читабельности, система поймет и без них:
Так правильно
Так тоже правильно
Ключ — ВСЕГДА строка, но мы все равно берем его в кавычки. В JavaScript этого можно не делать, в JSON нельзя.
Так правильно
Так правильно в JS, но неправильно в JSON
По крайней мере, если вы работаете с простыми значениями ключей, а несколько слов записываете в верблюжьемРегистре или в змеином_регистре. Если вы хотите написать в ключе несколько слов через пробел, ключ нужно взять в кавычки.
my query: «Виктор Иван»
«my query»: «Виктор Иван»
И все же я рекомендую использовать простые названия ключей, или использовать snake_case.
Писать ключи можно в любом порядке. Ведь JSON-объект — это неупорядоченное множество пар «ключ:значение».
Так правильно
Так тоже правильно
Очень важно это понимать, и тестировать! Принимающая запрос система должна ориентировать на название ключей в запросе, а не на порядок их следования. Ключевое слово «должна» )) Хотя знаю примеры, когда от перестановки ключей местами всё ломалось, ведь «первым должен идти запрос, а не count!».
Ключ или свойство?
Вот у нас есть JSON-объект:
Что такое «query»? Если я хочу к нему обратиться, как мне это сказать? Есть 2 варианта, и оба правильные:
— Обратиться к свойству объекта;
— Получить значение по ключу.
То есть «query» можно назвать как ключом, так и свойством. А как правильно то?
Правильно и так, и так! Просто есть разные определения объекта:
Объект
В JS объект — это именно объект. У которого есть набор свойств и методов:
Свойства — описывают, ЧТО мы создаем.
Методы — что объект умеет ДЕЛАТЬ.
То есть если мы хотим создать машину, есть два пути:
Перечислить 10 разных переменных — модель, номер, цвет, пробег.
Создать один объект, где будут все эти свойства.
Аналогично с кошечкой, собачкой, другом из записной книжки.
Объектно-ориентированное программирование (ООП) предлагает мыслить не набором переменных, а объектом. Хотя бы потому, что это логичнее. Переменных в коде будет много, как понять, какие из них взаимосвязаны?
Вот если я создаю машину, сколько переменных мне надо заполнить? А если меняю данные? А если удаляю? Когда переменные разбросаны по коду, можно забыть про какую-то и получить ошибку в интерфейсе. А если у нас есть цельный объект, всегда можно посмотреть, какие у него есть свойства и методы.
Например, создадим кошечку:
В объекте cat есть:
Свойства — name, year (что это за кошечка)
Функции — sleep (что она умеет делать, описание поведения)
По коду сразу видно, что у кошечки есть имя и возраст, она умеет спать. Если разработчик решит добавить новые свойства или методы, он дополнит этот объект, и снова всё в одном месте.
Если потом нужно будет получить информацию по кошечке, разработчик сделает REST-метод getByID, searchKitty, или какой-то другой. А в нем будет возвращать свойства объекта.
То есть метод вернет
И при использовании имени вполне уместно говорить «обратиться к свойству объекта». Это ведь объект (кошечка), и его свойства!
Набор пар «ключ:значение»
Второе определение объекта — неупорядоченное множество пар ключ:значение, заключенное в фигурные скобки <>.
Оно применимо тогда, когда внутри фигурных скобок приходит не конкретный целостный объект, а просто набор полей. Они могут быть связаны между собой, а могут относится к совершенно разным объектам внутри кода:
client_fio (в коде это свойство fio объекта client)
kitty_name (в коде это свойство name объекта cat)
car_model (в коде это свойство model объекта car)
В таком случае логично называть эти параметры именно ключами — мы хотим получить значение по ключу.
Но в любом случае, и «ключ», и «свойство» будет правильно. Не пугайтесь, если в одной книге / статье / видео увидели одно, в другой другое. Это просто разные трактовки ¯\_(ツ)_/¯
Итого
Json-объект — это неупорядоченное множество пар «ключ:значение», заключённое в фигурные скобки «< >». Ключ описывается строкой, между ним и значением стоит символ «:». Пары ключ-значение отделяются друг от друга запятыми.
Значения ключа могут быть любыми:
И только строку мы берем в кавычки!
JSON-массив
Как устроен
Давайте снова начнем с примера. Это массив:
Массив заключен в квадратные скобки []
Внутри квадратных скобок идет набор значений. Тут нет ключей, как в объекте, поэтому обращаться к массиву можно только по номеру элемента. И поэтому в случае массива менять местами данные внутри нельзя. Это упорядоченное множество значений.
Значения разделены запятыми:
Значения внутри
Внутри массива может быть все, что угодно:
Цифры
Строки
Смесь
Объекты
Да, а почему бы и нет:
Или даже что-то более сложное. Вот пример ответа подсказок из Дадаты:
Система возвращает массив подсказок. Сколько запросили в параметре count, столько и получили. Каждая подсказка — объект, внутри которого еще один объект. И это далеко не сама сложная структура! Уровней вложенности может быть сколько угодно — массив в массиве, который внутри объекта, который внутри массива, который внутри объекта.
Ну и, конечно, можно и наоборот, передать массив в объекте. Вот пример запроса в подсказки:
Это объект (так как в фигурных скобках и внутри набор пар «ключ:значение»). А значение ключа «parts» — это массив элементов!
Итого
Массив — это просто набор значений, разделенных запятыми. Находится внутри квадратных скобок [].
А вот внутри него может быть все, что угодно:
смесь из всего вышеназванного
JSON vs XML
В SOAP можно применять только XML, там без вариантов.
В REST можно применять как XML, так и JSON. Разработчики отдают предпочтение json-формату, потому что он проще воспринимается и меньше весит. В XML есть лишняя обвязка, название полей повторяется дважды (открывающий и закрывающий тег).
Сравните один и тот же запрос на обновление данных в карточке пользователя:
JSON
За счет того, что мы не дублируем название поля каждый раз «surname – surname», читать JSON проще. И за счет этого же запрос меньше весит, что при плохом интернете бывает важно. Или при большой нагрузке.
Well Formed JSON
Разработчик сам решает, какой JSON будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. Наш JSON должен быть well formed, то есть синтаксически корректный.
Чтобы проверить JSON на синтаксис, можно использовать любой JSON Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.
Но учтите, что парсеры внутри кода работают не по википедии или w3schools, а по RFC, стандарту. Так что если хотите изучить «каким должен быть JSON», то правильнее открывать RFC и искать там JSON Grammar. Однако простому тестировщику хватит набора типовых правил с w3schools, их и разберем.
Правила well formed JSON:
Данные написаны в виде пар «ключ:значение»
Данные разделены запятыми
Объект находится внутри фигурных скобок <>
Массив — внутри квадратных []
1. Данные написаны в виде пар «ключ:значение»
В JSON название ключа нужно брать в кавычки, в JavaScript не обязательно — он и так знает, что это строка. Если мы тестируем API, то там будет именно JSON, так что кавычки обычно нужны.
Но учтите, что это правило касается JSON-объекта. Потому что json может быть и числом, и строкой. То есть:
Это тоже корректный json, хоть и не в виде пар «ключ:значение».
И вот если у вас по ТЗ именно json-объект на входе, попробуйте его сломать, не передав ключ. Ещё можно не передать значение, но это не совсем негативный тест — система может воспринимать это нормально, как пустой ввод.
2. Данные разделены запятыми
Пары «ключ:значение» в объекте разделяются запятыми. После последней пары запятая не нужна!
Типичная ошибка: поставили запятую в конце объекта:
Это последствия копипасты. Взяли пример из документации, подставили в постман (ну или разработчик API подставил в код, который будет вызывать систему), а потом решили поменять поля местами.
Смотрим на запрос — ну, query то важнее чем count, надо поменять их местами! Копипастим всю строку ««count»: 7,», вставляем ниже. Перед ней запятую добавляем, а «лишнюю» убрать забываем. По крайней мере у меня это частая ошибка, когда я «кручу-верчу, местами поменять хочу».
Другой пример — когда мы добавляем в запрос новое поле. Примерный сценарий:
У меня уже есть работающий запрос в Postman-е. Но в нем минимум полей.
Копирую из документации нужное мне поле. Оно в примере не последнее, так что идёт с запятой на конце.
Вставляю себе в конце запроса — в текущий конец добавляю запятую, потом вставляю новую строку.
Отправляю запрос — ой, ошибка! Из копипасты то запятую не убрала!
Я на этот сценарий постоянно напарываюсь при тестировании перестановки полей. А ведь это нужно проверять! Хороший запрос должен быть как в математической присказке: «от перемены мест слагаемых сумма не меняется».
Не зря же определение json-объекта гласит, что «это неупорядоченное множество пар ключ:значение». Раз неупорядоченное — я могу передавать ключи в любом порядке. И сервер должен искать по запросу название ключа, а не обращаться к индексу элемента.
Разработчик, который будет взаимодействовать с API, тоже человек, который может ошибиться. И если система будет выдавать невразумительное сообщение об ошибке, можно долго думать, где конкретно ты налажал. Поэтому ошибки тоже тестируем.
Чтобы протестировать, как система обрабатывает «плохой json», замените запятую на точку с запятой:
Или добавьте лишнюю запятую в конце запроса — эта ошибка будет встречаться чаще!
Или пропустите запятую там, где она нужна:
Аналогично с массивом. Данные внутри разделяются через запятую. Хотите попробовать сломать? Замените запятую на точку с запятой! Тогда система будет считать, что у вас не 5 значений, а 1 большое:
*Я добавила комментарии внутри блока кода. Но учтите, что в JSON комментариев нет. Вообще. Так что если вы делаете запрос в Postman, не получится расставить комментарии у разных строчек в JSON-формате.
3. Объект находится внутри фигурных скобок <>
Чтобы сломать это условие, уберите одну фигурную скобку:
Или попробуйте передать объект как массив:
Ведь если система ждет от вас в запросе объект, то она будет искать фигурные скобки.
4. Массив — внутри квадратных []
Чтобы сломать это условие, уберите одну квадратную скобку:
Или попробуйте передать массив как объект, в фигурных скобках:
Ведь если система ждет от вас в запросе массив, то она будет искать квадратные скобки.
Итого
JSON (JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Легко читается человеком и машиной. Часто используется в REST API (чаще, чем XML).
Корректные значения JSON:
JSON-объект — неупорядоченное множество пар «ключ:значение», заключённое в фигурные скобки «< >».
Массив — упорядоченный набор значений, разделенных запятыми. Находится внутри квадратных скобок [].
Число (целое или вещественное).
Литералы true (логическое значение «истина»), false (логическое значение «ложь») и null.
При тестировании REST API чаще всего мы будем работать именно с объектами, что в запросе, что в ответе. Массивы тоже будут, но обычно внутри объектов.
Комментариев в JSON, увы, нет.
Правила well formed JSON:
Данные в объекте написаны в виде пар «ключ:значение»
Данные в объекте или массиве разделены запятыми