-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
XML vs JSON
- Автор темы Alex Bond
- Дата начала
В общем случае это кретинизм, простой php array прекрасно подходит и не нужно юзать 100 слоёв кэша. Я вот узаю кое где ini файлы, так одни проблемы с парсингом под разные версии php, плююсь но продолжаю грызть кактус 
.
Но в частном, если разработчик грамотный, то у xml есть преимущество в удобной валидации через dtd или xml schema.
. Но в частном, если разработчик грамотный, то у xml есть преимущество в удобной валидации через dtd или xml schema.
tz-lom
Продвинутый новичок
Alex Bond
задачу чего?
для XML в своё время было написано некоторое количество тулзов которые по описанию сервиса генерили код для работы с оным, тогда это выглядело круто и прикольно - суёшь URL а на выходе классы, которые ты просто дёргаешь и сервис вызывается. На практике - скатилось в УГ т.к. описать сервис руки-хуки нормально не могут,а по кривому сервису и код не генерится (или генерится,но не тот). Итог - ламеры не могут работать т.к. не работает, люди знающие "развлекаются" исправлениями чужих косяков (dtd и shema для валидации сервисов конечно есть, но кто их юзает при разработке? единицы)
ИРЛ - апилка она и есть апилка, сильно сложными они так и не стали, сильно простыми тоже
массивы РНР кидать - глупое занятие т.к. не РНР единым
JSON используют,но не все и не всегда, ну и ладно, кстати стандарт JSON RPC есть, но всем как всегда ...
существующее положение дел сводится к следующему:
если хочешь чтобы твои API использовали - пиши биндинги на С++, РНР, перл, джаву, питон, дотнет сам, ну или будь гуглом, тогда их напишут за тебя(иногда - весьма криво,что тоже доставит тем кто с ними будет работать)
ну а дальше - кто во что горазд
задачу чего?
для XML в своё время было написано некоторое количество тулзов которые по описанию сервиса генерили код для работы с оным, тогда это выглядело круто и прикольно - суёшь URL а на выходе классы, которые ты просто дёргаешь и сервис вызывается. На практике - скатилось в УГ т.к. описать сервис руки-хуки нормально не могут,а по кривому сервису и код не генерится (или генерится,но не тот). Итог - ламеры не могут работать т.к. не работает, люди знающие "развлекаются" исправлениями чужих косяков (dtd и shema для валидации сервисов конечно есть, но кто их юзает при разработке? единицы)
ИРЛ - апилка она и есть апилка, сильно сложными они так и не стали, сильно простыми тоже
массивы РНР кидать - глупое занятие т.к. не РНР единым
JSON используют,но не все и не всегда, ну и ладно, кстати стандарт JSON RPC есть, но всем как всегда ...
существующее положение дел сводится к следующему:
если хочешь чтобы твои API использовали - пиши биндинги на С++, РНР, перл, джаву, питон, дотнет сам, ну или будь гуглом, тогда их напишут за тебя(иногда - весьма криво,что тоже доставит тем кто с ними будет работать)
ну а дальше - кто во что горазд
~WR~
Новичок
Обратил внимание, что все последние API, с которыми работал, позволяют указать тип возвращаемых данных. И могут вернуть как XML, так и JSON. Нет проблем.
Реальный смысл в XML вижу только при передаче очень больших объемов информации, типа прайс-листов. Именно на больших объемах сильно помогает "читаемость". Но до сих пор не понимаю, зачем там нужны namespace. Видимо, для того, чтобы себя запутать побольше.
Реальный смысл в XML вижу только при передаче очень больших объемов информации, типа прайс-листов. Именно на больших объемах сильно помогает "читаемость". Но до сих пор не понимаю, зачем там нужны namespace. Видимо, для того, чтобы себя запутать побольше.
~WR~
Новичок
Я о другом.
Например, в случае яндекс маркета часто возникают вопросы, попали есть ли определенный товар в XML, и с какими параметрами он реально выгрузился на момент N. Я просто захожу в архив и делают поиск по подстроке. И сразу нахожу то, что нужно.
Например: <offer id="12345"
В JSON или в CSV искать тяжелее. В прайсах на миллион позиций комбинации цифр повторяются часто. А даже если найдешь нужную строку - её еще надо расшифровать. А в XML все сразу видно.
Единственный плюс XML для меня.
Например, в случае яндекс маркета часто возникают вопросы, попали есть ли определенный товар в XML, и с какими параметрами он реально выгрузился на момент N. Я просто захожу в архив и делают поиск по подстроке. И сразу нахожу то, что нужно.
Например: <offer id="12345"
В JSON или в CSV искать тяжелее. В прайсах на миллион позиций комбинации цифр повторяются часто. А даже если найдешь нужную строку - её еще надо расшифровать. А в XML все сразу видно.
Единственный плюс XML для меня.
