xml xsd wsdl что это

В чем разница между XSD и WSDL

ОТВЕТЫ

Ответ 1

XSD определяет схему, которая представляет собой определение того, как XML-документ может быть структурирован. Вы можете использовать его для проверки того, что данный XML-документ действителен и соответствует правилам, которые вы указали в схеме.

Документы WSDL имеют связанный с ним XSD, который показывает, что является допустимым для размещения в документе WSDL.

Ответ 2

XSD (Xml Schema Definition) описывает статическую структуру сложных типов данных, обмениваемых этими сервисными методами. Он описывает типы, их поля, любое ограничение на эти поля (например, максимальную длину или шаблон регулярного выражения) и т.д.

Ответ 3

XSD: определение схемы XML.

XML: расширяемый язык разметки.

WSDL: язык определения веб-сервисов.

Я не собираюсь отвечать технически. Я направляю это объяснение на новичков.

Нелегко общаться между двумя различными приложениями, которые разрабатываются с использованием двух разных технологий. Например, компания в Чикаго может разработать веб-приложение с использованием Java, а другая компания в Нью-Йорке может разработать приложение на С#, и когда эти две компании решили обмениваться информацией, тогда XML появится в картине. Он помогает хранить и транспортировать данные между двумя различными приложениями, которые разрабатываются с использованием разных технологий. Примечание. Это не ограничивается языком программирования, пожалуйста, исследуйте транспортировку информации между двумя различными приложениями.

*************** ======== Ниже представлено частичное изображение XML ========== ********* ******

Мне пришлось создать образец WSDL для веб-службы под названием «Книга». Обратите внимание, что это XSD, но вы должны назвать его WSDL (язык определения веб-сервисов), потому что он очень специфичен для веб-служб. Ниже WSDL (или, другими словами, XSD) создается для класса Book.java, и он создал службу SOAP. Как создала веб-служба SOAP, это другая тема. Нужно написать класс Java, и перед выполнением его создания в качестве веб-службы пользователь должен убедиться, что Axis2 API установлен, и Tomcat для размещения веб-службы на месте.

В качестве сервис-провайдера (тот, кто позволяет другим (клиентам) получать доступ к информации или данным из своих систем) фактически дает клиенту (тем, кто должен использовать информацию или данные сервис-провайдера) полный доступ к данным через веб-службу, ни одна компания на земле не готова предоставить свою базу данных для посторонних. Как и моя компания, я решил предоставить некоторую информацию о продуктах через веб-службы, поэтому нам пришлось создать шаблон XSD и передать некоторые из наших клиентов, которые хотят работать с нами. Они должны написать код для полного использования данного XSD и сделать вызовы Web Service для извлечения данных из servicer и преобразования данных, возвращенных в их подходящее требование, а затем отображать или публиковать данные или информацию о продукте на своем веб-сайте. Простым примером может служить бронирование авиабилетов FLIGHT. Авиакомпания позволит третьим сторонам использовать данные рейса на своем сайте для продажи билетов. Но опять-таки есть намного больше, просто не позволяя стороннему агентству по авиабилетам продавать билеты, там будут синхронизация и безопасность на месте. Если нет синхронизации, то вероятность 100% более одного клиента может купить тот же авиабилет из разных источников.

Я надеюсь, что эксперты будут способствовать моему ответу. Для новичков или новичков очень сложно понять XML, XSD, а затем работать с веб-службами.

Ответ 4

Ответ 5

XSD (определение схемы XML) определяет элемент в документе XML. Его можно использовать для проверки того, соответствуют ли элементы в документе xml описанию, в котором должен размещаться контент. В то время как wsdl является специфическим типом XML-документа, который описывает веб-службу. Сам WSDL придерживается XSD.

Ответ 6

Обратитесь: ayazroomy-java.blogspot.com, чтобы прочитать об основах webservice.

Ответ 7

Если кто-то ищет аналогию, этот ответ может быть полезен.

WSDL подобен команде «SHOW TABLE STATUS» в mysql. Он определяет все элементы (тип запроса, тип ответа, формат URL для запроса запроса и т.д.), Который должен быть частью XML. По определению я имею в виду: 1) Имена запроса или ответа 2) Что следует рассматривать как ввод, что следует рассматривать как выход.

XSD похож на команду DESC в mysql. Он сообщает, что все переменные и их типы, запрос и ответ содержат.

Ответ 8

Источник

в чем разница между XSD и WSDL

В чем разница между XML Schema и WSDL

6 ответов

XSD определяет схему, которая является определением того, как XML-документ может быть структурирован. Вы можете использовать его для проверки того, что данный XML-документ действителен и соответствует правилам, изложенным в схеме.

Документы WSDL имеют связанный XSD, в котором показано, что можно поместить в документ WSDL.

XSD (определение схемы XML) описывает статическую структуру сложных типов данных, которыми обмениваются эти сервисные методы. Он описывает типы, их поля, любые ограничения на эти поля (например, максимальная длина или шаблон регулярных выражений) и т. Д.

XSD: определение схемы XML.

XML: расширяемый язык разметки.

WSDL: язык определения веб-служб.

Я не собираюсь отвечать технически. Я нацеливаю это объяснение на начинающих.

Нелегко общаться между двумя разными приложениями, разработанными с использованием двух разных технологий. Например, компания в Чикаго может разработать веб-приложение с использованием Java, а другая компания в Нью-Йорке может разработать приложение на C #, и когда эти две компании решили обмениваться информацией, тогда возникает XML. Это помогает хранить и передавать данные между двумя различными приложениями, разработанными с использованием разных технологий. Примечание: это не ограничивается языком программирования, пожалуйста, изучите передачу информации между двумя различными приложениями.

*************** ======== Ниже приведено частичное изображение XML ========== ********* ******

Мне пришлось создать образец WSDL для веб-службы под названием Book. Обратите внимание, что это XSD, но вы должны называть его WSDL (язык определения веб-службы), поскольку он очень специфичен для веб-служб. Приведенный ниже WSDL (или, другими словами, XSD) создан для класса Book.java и создал службу SOAP. Как создавался веб-сервис SOAP, это другая тема. Нужно написать класс Java, и перед его созданием в качестве веб-службы пользователь должен убедиться, что Axis2 API установлен и Tomcat для размещения веб-службы на месте.

Как обслуживающий (тот, кто позволяет другим (клиентам) получать доступ к информации или данным из их систем) фактически предоставляет клиенту (тому, кому необходимо использовать информацию или данные обслуживающего устройства) полный доступ к данным через веб-службу, потому что ни одна компания на земле не желает раскрывать свою базу данных для посторонних. Как и моя компания, решил предоставить некоторую информацию о продуктах через веб-сервисы, поэтому нам пришлось создать шаблон XSD и передать его нескольким нашим клиентам, которые хотят с нами работать. Они должны написать некоторый код, чтобы в полной мере использовать данный XSD и сделать вызовы веб-службы для извлечения данных из обслуживающего устройства и преобразования данных, возвращенных в их подходящее требование, а затем для отображения или публикации данных или информации о продукте на своем веб-сайте. Простой пример будетПОЛЕТ Бронирование билетов. Авиакомпания позволит третьим сторонам использовать данные о рейсах на своем сайте для продажи билетов. Но опять же, это намного больше, это просто не позволяет стороннему агенту по продаже авиабилетов продавать билеты, будет синхронизация и безопасность на месте. Если синхронизация отсутствует, существует 100% вероятность того, что один и тот же клиент может купить один и тот же авиабилет из разных источников.

Я надеюсь, что эксперты ответят на мой вопрос. Новичку или новичку действительно трудно понять XML, XSD, а затем работать с веб-сервисами.

Источник

в чем разница между XSD и WSDL

7 ответов

XSD определяет схему, которая является определением того, как XML-документ может быть структурирован. Вы можете использовать его, чтобы проверить, что данный XML-документ действителен и следует правилам, изложенным в схеме.

WSDL-это XML-документ, описывающий веб-сервис. Он показывает, какие операции доступны и как данные должны быть структурированы для отправки в эти операции.

документы WSDL имеют связанный XSD, который показывает, что допустимо поместить в документ WSDL.

xsd-схемы (определение схемы Xml) описывает статическую структуру сложных типов данных, которыми обмениваются эти методы службы. Он описывает типы, их поля, любые ограничения на эти поля (например, максимальная длина или шаблон регулярного выражения) и т. д.

Это описание типов данных и, следовательно, статических свойств сервиса-это данные.

XSD: определение схемы XML.

XML: расширяемый язык разметки.

WSDL: язык определения веб-службы.

Я не собираюсь отвечать в техническом плане. Я направляю это объяснение на начинающих.

XSD-это определение схемы. Под этим я подразумеваю, что он говорит пользователям разрабатывать свой XML в таком схема. См. ниже изображения и внимательно следите за элементом «load-on-startup» и его типом, который является целочисленным. В изображении XSD вы можете видеть, что это должно быть целочисленное значение для «load-on-startup», и, следовательно, когда пользователь создал свой XML, они передали значение int этому конкретному элементу. Напомним, что XSD-это схема и стиль, а XML-это форма для взаимодействия с другим приложением или системой. Нужно видеть XSD и создавать XML таким образом, иначе он не будет взаимодействовать с другое приложение или система, которая была разработана с использованием другой технологии. Компания в Чикаго предоставляет шаблон XSD для компании в Техасе, чтобы написать или создать свой XML в данном формате XSD. Если компания в Техасе не смогла придерживаться этих правил или схемы, упомянутых в XSD, то невозможно ожидать правильной информации от компании в Чикаго. После вышеупомянутой истории так много нужно сделать, что любитель или новичок должен знать, кодируя что-то вроде Я сказал выше. Если вы действительно хотите знать, что произойдет позже, то лучше сидеть со старшими инженерами-программистами, которые на самом деле разработали веб-сервисы. Далее идет WSDL, пожалуйста, следуйте изображениям и попытайтесь выяснить, где WSDL будет вписываться.

***************========Ниже приведен частичный XML-образ ==========***************

Мне пришлось создать образец WSDL для веб-службы под названием Book. Обратите внимание, что это XSD, но вы должны назвать его WSDL (язык определения веб-службы), потому что он очень специфичен для веб-служб. Ниже WSDL (или, другими словами, XSD) создается для класса под названием Book.java и он создал SOAP-сервис. Как веб-служба SOAP создала другую тему. Нужно написать класс Java и перед его выполнением создать как веб-службу, пользователь должен убедиться, что AXIS2 API установлен и Tomcat для размещения веб-службы на месте.

Как сервисер (тот, кто позволяет другим (клиентам) получать доступ к информации или данным из своих систем ) фактически предоставляет клиенту (тому, кто должен использовать информацию или данные сервисера) полный доступ к данным через веб-службу, потому что ни одна компания на земля готова открыть свою базу данных для посторонних. Как и моя компания, решила предоставить некоторую информацию о продуктах через веб-сервисы, поэтому нам пришлось создать шаблон XSD и передать его немногим из наших клиентов, которые хотят работать с нами. Они должны написать некоторый код, чтобы полностью использовать данный XSD и совершать вызовы веб-служб для извлечения данных из servicer и преобразования данных, возвращенных в их подходящее требование, а затем отображать или публиковать данные или информацию о продукте на своих вебсайт. Простым примером может служить бронирование авиабилетов. Авиакомпания позволит третьим лицам использовать данные о рейсах на своем сайте для продажи билетов. Но опять же есть гораздо больше к нему, это просто не давая третьей стороне агент по продаже билетов, там будет синхронизация и безопасность на месте. Если нет синхронизации, то есть 100% вероятность того, что более 1 клиента могут купить один и тот же билет из разных источников.

Я надеюсь, что эксперты внесут свой вклад в мой ответ. Это очень трудно новичку или новичку понять XML, XSD, а затем работать с веб-службами.

Источник

Что такое XML

Если вы тестируете API, то должны знать про два основных формата передачи данных:

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.

Содержание

Как устроен XML

Возьмем пример из документации подсказок Дадаты по ФИО:

И разберемся, что означает эта запись.

В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:

Текст внутри угловых скобок — название тега.
Тега всегда два:

Ой, ну ладно, подловили! Не всегда. Бывают еще пустые элементы, у них один тег и открывающий, и закрывающий одновременно. Но об этом чуть позже!

С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:

— На въезде в город написано его название: Москва
— На выезде написано то же самое название, но перечеркнутое: Москва*

* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!

Корневой элемент

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.

Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».

Он мог бы называться по другому:

Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.

Значение элемента

Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.

Внутри — значение запроса.

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.

Атрибуты элемента

У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

Давайте разберем эту запись. У нас есть основной элемент party.

У него есть 3 атрибута:

Внутри party есть элементы field.

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;
— у него есть элементы field;
— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. ТЗ может устареть, а код будет актуален.
— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.

В общем, любой подход имеет право на существование. Надо смотреть по проекту, что будет удобнее именно вам. У меня в примере неговорящие названия элементов — все как один будут field. А вот по атрибутам уже можно понять, что это такое.

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:

У элемента attribute есть атрибуты:

Такая вот XML-ка получилась. Причем упрощенная. В реальных системах, где хранятся физ лица, данных сильно больше: штук 20 полей самого физ лица, несколько адресов, телефонов, емейл-адресов…

Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

XML пролог

Иногда вверху XML документа можно увидеть что-то похожее:

Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.

UTF-8 — кодировка XML документов по умолчанию.

XSD-схема

XSD (XML Schema Definition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.

Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».

Если мы создаем SOAP-метод, то указываем в схеме:

Поэтому зачем запускать сложную процедуру, если запрос заведом «плохой»? И выдавать ошибку через 5 минут, а не сразу? Валидация по схеме помогает быстро отсеять явно невалидные запросы, не нагружая систему.

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

Итого, как используется схема при разработке SOAP API:

Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:

А в WSDl сервиса она записана еще проще:

Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:

А еще в схеме можно ссылаться на другую схему, что упрощает написание кода — можно переиспользовать схемы для разных задач.

Практика: составляем свой запрос

Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!

Что, если я хочу, чтобы мне вернуть только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:

В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:

Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. «Женский» по английски будет FEMALE, в документации также. Итого получили:

Ненужное можно удалить. Если нас не волнует количество подсказок, параметр count выкидываем. Ведь, согласно документации, он необязательный. Получили запрос:

Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))

Попробуй сам!
Напишите запрос для метода MagicSearch в Users. Мы хотим найти всех Ивановых по полному совпадению, на которых висят актуальные задачи.

Well Formed XML

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

1. Есть корневой элемент

Нельзя просто положить рядышком 2 XML и полагать, что «система сама разберется, что это два запроса, а не один». Не разберется. Потому что не должна.

И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:

Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!

2. У каждого элемента есть закрывающийся тег

Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.

Но тут стоит заметить, что тег может быть один. Если элемент пустой, мы можем обойтись одним тегом, закрыв его в конце:

Это тоже самое, что передать в нем пустое значение

Аналогично сервер может вернуть нам пустое значение тега. Можно попробовать послать пустые поля в Users в методе FullUpdateUser. И в запросе это допустимо (я отправила пустым поле name1), и в ответе SOAP Ui нам именно так и отрисовывает пустые поля.

Итого — если есть открывающийся тег, должен быть закрывающийся. Либо это будет один тег со слешом в конце.

Для тестирования удаляем в запросе любой закрывающийся тег.

3. Теги регистрозависимы

Как написали открывающий — также пишем и закрывающий. ТОЧНО ТАК ЖЕ! А не так, как захотелось.

А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным

4. Правильная вложенность элементов

Элементы могут идти друг за другом

Один элемент может быть вложен в другой

Но накладываться друг на друга элементы НЕ могут!

5. Атрибуты оформлены в кавычках

Даже если вы считаете атрибут числом, он будет в кавычках:

Для тестирования пробуем передать его без кавычек:

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

Хранение данных — это когда XML встречается внутри кода. Его легко понимает как машина, так и человек. В формате XML можно описывать какие-то правила, которые будут применяться к данным, или что-то еще.

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.

Правила well formed XML:

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

Что такое JSON — второй популярный формат

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Источник