Я стараюсь не использовать его больше, чем нужно. Он определенно имеет свое место в качестве протокола передачи в архитектуре, где клиент и сервер не знают друг о друге и реализуются независимо - или API разрабатывается независимо от любых клиентов. У него также есть постоянное место, где применимы те же аргументы, и я гораздо меньше возражаю против этого в этой области.
Однако, если клиент и сервер реализованы одной и той же командой, то нет смысла переводить их туда и обратно в удобочитаемой форме, и почти всегда есть более быстрая, более дешевая (с точки зрения обработки) альтернатива. , даже если технологии клиента и сервера разные.
Сосредоточив свои замечания на протоколах передачи, еще до того, как XML пришел в «плохие» старые времена клиент / сервер, когда пропускная способность и вычислительная мощность были драгоценными, архитекторам было бы необходимо разработать протокол (обычно двоичный) с единственная работа эффективности и скорости, где размер пакета будет минимизирован. Очевидным ограничением является то, что рукопожатие было очень конкретным, а бинарный диалект был непонятным, если он не был опубликован. Положительным моментом было то, что он был чрезвычайно эффективным и мог быть высоко оптимизирован для применения под рукой. Очень часто бинарные форматы публиковались (вы видели старую спецификацию Excel BIFF - не протокол, а пример публикации бинарного формата).
XML в HTTP, т. Е. SOAP, сломал это. Обоснование было очень вменяемым, иметь общепринятый протокол для рукопожатия, своего рода компьютер Esperanto , так что вы могли бы разделить архитектуру вашего клиента и сервера и решать их темпы разработки и внутренние компоненты совершенно отдельно. Более того, вы можете защитить себя от возможных требований клиентов, пообещав, что переключение клиентов - это всего лишь вопрос внедрения нового. Более того, позвольте любому Joe с парсером XML использовать ваш API. Все это великолепно и привело к появлению очень хорошо размеченных архитектур - что совершенно неплохо.
Таким образом, в значительной степени сила этого предложения была проявлена и есть явные преимущества, однако я думаю, что а) это требование часто завышено и б) протоколы XML часто реализуются очень небрежно и с недостаточным вниманием к стоимость обработки они подразумевают. Более того, изначально здравомыслящие рассуждения уступили место случаям экстремистской религии (держу пари, что за меня проголосовали), и я видел код, передающий XML между вызовами функций в одних и тех же классах , используя именно обоснование будущего и аргументы функционального разделения, что явно помешано.
Итак, моя мантра - сделать общение эффективным и действенным. Если это означает предоставление обобщенного API и протокола для произвольных и неизвестных потребителей, то XML является очень хорошим выбором. Если это означает создание молниеносной, масштабируемой клиент-серверной (то есть веб-) архитектуры, то я пытаюсь использовать двоичный протокол, часто использующий мой собственный.
Появление JSON свидетельствует о том, что в XML-фургоне было слишком много уровней. JSON - это попытка сократить структурные элементы при сохранении общности и тем самым получить преимущества меньших пакетов. Протоколы, такие как AMF от Adobe, обычно намного более компактны и почти полностью бинарны.
И вот где я думаю, что будущее, вероятно, лежит. Я уверен, что будет возможно сохранить все положительные стороны, которые XML представляет для публикации интерфейсов, но иметь возможность резко обрезать его и сделать его менее интенсивным по процессору и пропускной способности - по крайней мере, это моя миссия как разработчика и архитектора.
Представьте, что ваш средний клиент / серверный запрос был 1/10 от размера и текст не разбирался ни на одном конце, но вы сохранили общность интерфейса. Я не знаю ни одного разработчика, который бы этого не принял.