Что самое неприятное, проблема задевает почти все ключевые элементы интерфейса.

Что сломалось

Поломка затронула компоненты Windows Shell, завязанные на XAML. Из-за ошибки начинают разваливаться:

• меню «Пуск» (StartMenuExperienceHost),
• «Проводник» (Explorer.exe),
• «Панель задач»,
• «Настройки Windows» (SystemSettings),

В общем, все, что открывается в Windows не через .exe из «Program Files», а через современные компоненты Shell.

Microsoft уточняет, что баг возникает:

• при первом входе пользователя после установки обновления,
• при каждом входе в системы, работающие как VDI / непостоянные образы (где приложения разворачиваются заново).

Откуда вообще взялась проблема

Оказалось, что источник бага — июльское обновление Windows 11 (KB5062553). То есть все ломалось еще четыре месяца назад, но теперь Microsoft наконец признала ошибку.

И да, свежее обновление Windows 11 25H2 тоже затронуто. В конце концов, в его основе лежит все тот же код.

Выяснилось, что во всем по итогу виноваты пакеты:

• MicrosoftWindows.Client.CBS_cw5n1h2txyewy,
• Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe,
• MicrosoftWindows.Client.Core_cw5n1h2txyewy.

Они обновляются вместе с системой и рушат XAML-инфраструктуру. Microsoft уже перечислила характерные признаки проблемы:

• падение Explorer.exe и ShellHost.exe;
• пустая или неработающая панель задач;
• «Пуск» не открывается;
• настройки не запускаются без ошибок — просто молча закрываются;
• XAML-интерфейсы не прогружаются;
• ImmersiveShell ведет себя как будто его удалили.

Временные решения

Патча, исправляющего баг, пока нет. Но Microsoft предлагает два костыля:

Перерегистрация системных пакетов (PowerShell)

Скрипт для входа в систему

Microsoft также рекомендует задерживать запуск Explorer.exe, пока не подгрузятся нужные пакеты.

Что дальше

Microsoft работает над официальным фиксом, но сроков пока нет. Проблема серьезная: ломаются не приложения, а базовые механизмы системы. Поэтому и исправление будет разрабатываться явно не один день.

Зачем вообще писать комментарии в коде?

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

Какие задачи они решают ?

1. Пояснить неочевидное

Код показывает «что» делает программа, а комментарий — «зачем».

Такой комментарий не просто поясняет логику — он экономит десятки минут будущего чтения.

2. Предупредить

В коде бывает странное поведение. Иногда это не баг, а фича. И если не предупредить, другой разработчик обязательно «поправит» и всё сломает. Комментарий защитит от этого:

3. Пометить незавершёнку

TODO, FIXME, HACK — это специальные маячки. Их ставят туда, где нужно что-то доделать, починить или переписать по-человечески.

Бонусом, IDE умеют обрабатывать такие заметки, каждая по-своему.

4. Временно отключить код

Иногда нужно что-то закомментировать, чтобы проверить гипотезу. Но такой код нельзя оставлять надолго. Если от него нет пользы — в мусор. Историю всё равно сохранит git.

5. Объяснить архитектуру

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

6. Генерация документации

Многие языки и фреймворки поддерживают специальные форматированные комментарии для генерации документации. Например, JavaDoc в Java, docstring в Python, XML в C# – предназначены для описания интерфейсов: что делает функция или класс, какие имеют входные параметры и какой результат дают. Такие Комментарии выполняют роль пользовательской документации прямо в коде и могут автоматически собираться в справочник по API.

7. Пошутить

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

Как видно, диапазон применения комментариев очень широк. Но одинаково ли хорошо все эти виды влияют на качество кода? Рассмотрим случаи, когда комментарии приносят пользу, а когда создают проблемы.

Когда комментарии помогают

А часто без комментариев в коде сложно разобраться, особенно когда код чужой.

1. Когда логика не лежит на поверхности

Есть участки кода, где без контекста трудно разобраться, даже если код написан довольно читабельно. Например, сложная формула, нетривиальный алгоритм или необычная структура данных – всё, что выбивается из обыденного опыта разработчиков. В таких случаях пара строк комментария, резюмирующих подход, или объясняющих, что происходит, сэкономят часы на анализ. Это особенно важно для командной работы: коллегам, незнакомым с модулем, не придётся разбираться «с нуля».

2. Когда нужно документировать контракты и условия

Комментарии могут использоваться для обозначения контрактов – предусловий и постусловий функций, инвариантов и т.д. (подход Design by Contract). Хотя современные языки позволяют выразить многое (например, через assert или декораторы), комментарии могут дополнять код уточнениями вроде:

Также текстовые пометки в коде полезны для фиксации граничных условий и особых случаев, таких как обработка пустных массивов в бинарном поиске, другой пример:

Да, можно это выразить через assert, но комментарий дает сразу и контекст, и предупреждение. Особенно если логика непростая.

3. Когда нужно предоставить контекст и ссылки

Иногда кусок кода существует благодаря внешнему источнику, например, когда решение просто скопировано из ответа на форуме или из книги по теме. Просто так его не понять — нужна ссылка на источник:

4. Когда нужно облегчить ревью

Когда код содержит много пояснений к его работе новому участнику команды проще входить в проект – по сути, комментарии выполняют роль встроенной документации. Кроме того, код-ревью проходит эффективнее, если автор сразу помечает неочевидные места комментариями. Например:

В PEP 8 (стиле кодирования Python) прямо приводится пример: комментарий “Compensate for border” – полезный, в отличие от банального “Increment x”, который не даёт новой информации.

5. Когда нужна поддержка самодокументируемости через структуру

Иногда хочется написать: # Этап 1: авторизация пользователя, и в этот момент приходит мысль — а почему бы не вынести это в функцию authorize_user()? И комментарий уже не нужен. То есть сам порыв объяснить словами часто указывает, что код пора расчленить и упростить.

6. Когда нужно кого-то обучить программированию или корпоративным стандартам оформления кода

Когда человек обучается программированию или только пришел в компанию, где есть свои стандарты, комментарии в коде можно использовать, чтобы дать ему обучающий материал с примерами из практики, пример:

Комментарий — это инструмент. Если комментарий в коде дает информацию, которую нельзя вытащить из кода напрямую, — значит, работает как надо. Но бывает и обратное — когда комментарии мешают. Об этом — в следующей части.

Когда комментарии вредят

Худшее, что может случиться с комментариями – когда они вводят в заблуждение или засоряют код впустую. Рассмотрим подробнее:

Дублируют очевидное

Комментарий, который просто повторяет код своими словами, не несёт никакой пользы:

А вот так — лучше вообще без пояснений:

Комментарий должен объяснять, зачем что-то делается, а не что именно:

Врут и вводят в заблуждение

Классика: код переписали, а про комментарий забыли.

Спустя некоторое время код могли переписать, и old_api_call() заменили на new_api_call(), но комментарий остался от прежней версии и стал источником дезинформации: разработчик, читающий код, может принять заведомо неверное решение, доверившись устаревшей заметке. По этой причине крайне важно понимать: если уж пишете комментарий, держите его в актуальном состоянии вместе с кодом.

Показывают, что код плохой

Когда код плохо читается, и его пытаются «объяснить» словами, вместо того чтобы переписать:

Вместо этого — понятный код:

Плодятся бесконтрольно

Иногда встречается код, где каждое действие сопровождается избыточными пояснениями:

Здесь нет ни одной неочевидной строки. Лучше оставить так:

Представляют собой мёртвый код

Когда в коде остаются большие мёртвые блоки, которые просто закомментированы:

Может быть, раньше это что-то значило, но сейчас — просто мертвый груз. Если код не нужен — удаляй. История останется в git.

Запутывают и размывают смысл

Что значит «временное»? Когда переделывать? Почему не постоянное?

Лучше так:

Теперь ясно, почему так сделано, и можно отследить, когда это поведение закончится.

Итак, комментарии становятся злом, когда они не выполняют своей информативной роли, а лишь создают шум или дезинформируют. В худшем случае они могут привести к багам (если программист доверится неверному комментарию) и точно приведут к потере времени на их чтение и разбор. Единственный способ избежать этого зла — писать комментарии ответственно: убедиться, что они нужны, правдивы и своевременны.

Самодокументируемый код vs комментарии

Есть мечта у программистов — писать код, который объясняет сам себя. Без сносок, без подсказок, без комментариев. Такой код читается как инструкция: открыл — понял. Это и называется самодокументируемым стилем.

Как его достигают?

• Говорящие имена. Не x и a, а temperature, retryLimit, userProfile. Лучше сразу по имени понять, что перед тобой — массив с ID или словарь с настройками.
• Функции с характером. У функции должно быть имя-глагол, в котором есть ответ на вопрос “что делает этот код?”. Например: parseInvoice(), sendEmailReminder(), fetchUserByToken().
• Использовать названия для константных значений. Вместо if (status == 4) — if (status == ORDER_CONFIRMED). Вместо 3000 — RETRY_TIMEOUT_MS.
• Структура — как абзацы в тексте. Пустые строки, логические блоки, отступы — чтобы этапы выделялись сами собой.

Посмотрим например, где простой код поясняется ненужным комментарием:

Другой пример:

Комментарий уже не нужен. Из имён всё понятно: считаем среднюю температуру. Здесь самое интересное — само документируемость имеет границы. Потому что:

• Код объясняет «что», но не всегда «почему».

Вот есть строка:

А почему 5? Почему не 3, не 10? Если причина — ограничение API, бизнес-логика или чья-то странная прихоть — код не расскажет. А вот комментарий может:

Неочевидные решения и компромиссы

Иногда приходится делать что-то нестандартное. Например:

Такой кусок кода без пояснений вызовет недоумение: А почему не сортируем?

Старайтесь писать код так, чтобы его поняли без подсказок. Как будто у вас нет возможности что-то дополнительно объяснить. А если видите, что читателю будет трудно — помогите: добавьте комментарий, который действительно нужен.

Влияние ИИ и новых инструментов на подход к комментариям

В последние годы в распоряжении разработчиков появились мощные ассистенты на базе искусственного интеллекта — такие как GitHub Copilot (автодополнение кода на основе ИИ) и большие языковые модели вроде ChatGPT. Эти технологии начинают влиять и на практики комментирования кода.

Во-первых, автогенерация кода по комментариям стала реальностью.

Инструмент Copilot способен на лету написать фрагмент кода, ориентируясь на описания на естественном языке. Например:

Copilot тут же может подставить реализацию:

Такой подход превращает комментарий в своего рода промпт — описание задачи для ИИ. Это приучает писать коротко и по делу. Хотя такие комментарии потом часто удаляют, их роль в генерации кода становится всё важнее.

Во-вторых, ИИ сам пишет комментарии.

Можно просто показать код:

…и попросить ИИ: прокомментируй. В ответ он выдаст:

Или даже более детальный:

Такие автокомментарии могут быть полезны, но всё равно требуют проверки: всезнающий ИИ не всегда понимает скрытые нюансы логики, а часто просто галлюцинирует, поэтому доверять полностью не стоит, но, как черновик, вполне годится.

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

Раньше приходилось часами вчитываться, сегодня — можно просто спросить:

Запрос в ChatGPT: что делает эта функция?

Ответ: Она возвращает новый список, содержащий удвоенные значения тех элементов исходного списка, которые делятся на 3.

ИИ не волшебник, но в 90% случаев — удобный переводчик с машинного на человеческий. Это снимает часть нагрузки с необходимости документировать тривиальные вещи.

В-четвертых, новый тип комментариев: инструкции для ИИ

Может возникнуть ситуация, когда комментарий пишется не столько для человека, сколько как команда:

Если вы используете Cursor или Replit, это может очень полезным.

Заключение

Так всё-таки, комментарии – зло или спасение?

Это не абсолютное благо и не абсолютное зло, это просто инструмент. Всё зависит от того, в чьих он руках и зачем используется. Комментарии способны помочь понять неочевидные решения, разобраться в сложных структурах, подсказать направление для размышления. Но, как и любой инструмент, в неумелых руках это способ случайно (или не очень) испортить кровь себе и окружающим.

Но всё-таки чаще наличие комментариев делает жизнь лучше, ведь иногда формулирование мысли разговорным текстом, а не кодом, позволяет понять свою идею лучше, взглянуть на нее с другой стороны.

Мы в Smart Engines занимаемся разработкой софта для распознавания самых разных документов — начиная от паспорта РФ, свидетельства о рождении и заканчивая первичкой вроде УПД или ТОРГ-12, а также банковских карт, номеров телефона и баркодов. Наши библиотеки написаны полностью с нуля (на плюсах), мы уделяем огромное внимание скорости алгоритмов, нейросетям (новым архитектурам, размеру и правильному применению) и оптимизации, за счет чего наш софт портируется на любые архитектуры и может быть использован на любой платформе.

Сегодня продолжим знакомиться через рассказ о нашем софте, на очереди вторая библиотека — Smart Document Engine и ее возможности работы с жесткими и гибкими формами.

Гибкие и жесткие формы

Вначале про сами формы: они могут быть «жесткими» и «гибкими». Жёсткие формы подразумевают, что положение всех объектов на форме может быть задано прямо в виде координат на шаблоне. Самое простое определение для жестких форм — они совпадают «на просвет». Возьмите пару листов А4 с распечатанной жёсткой формой, наложите друг на друга, и места расположения полей точно совпадут. Гибкие формы устроены гораздо сложнее, но все равно имеют свою характерную структуру и топологию.

Распознавание жестких форм можно свести к детекции формы на изображении и распознавании определенных областей, где должны быть искомые поля. Гибкие формы требуют гораздо более сложных систем поиска (к тому же, завязанных на результате предыдущих действий, например, OCR, что только увеличивает возможность ошибки).

Кстати, иногда вместо распознавания текста целиком достаточно просто ответить на вопрос «есть ли текст в выбранной области, и, если есть, то где»

Но не надо думать, что жёсткие формы совсем просты — большие белые поля без каких-либо символов (или одинаковый узор по краям, как это бывает с бланками гособразца), малый объём статического текста и некоторая вариативность бланков тоже заставляют потрудиться над детекцией и классификацией шаблонов.

Также существуют общие для подобных форм проблемы. Правильно интерпретировать галочки в чекбоксах, найти штрихкоды, правильно разметить табличные данные — есть куча проблем, каждая из которых имеет своё state-of-the-art решение и набор алгоритмов, над которыми нужно ломать голову.

Почему не LLM, хотя казалось бы

Сейчас мы переживаем бум развития нейросетей — генеративные и классифицирующие сети появляются как грибы после дождя. Количество задач, которые они могут решить, тоже кажется неисчислимым: казалось бы — дайте обучающую выборку побольше, и всё получится! Тем более, что примеры использования нейросетей для автоматизации рутины уже можно встретить на каждом шагу: об этом пишут заметки и обзорные статьи на научно-популярных ресурсах, а интеграторы и стартапы предлагают решения по созданию чат-ботов и помощников на основе ИИ, обученного на внутренней документации больших компаний.

Однако чем сложнее нейросеть, чем глубже степень обучения — тем выше шанс, что она начнёт бредить. Мы все какое-то время назад смеялись над шести-семипалыми героями очередных сгенерированных изображений, сейчас посмеиваемся над сгенерированными сетями текстами с описанием несуществующих фильмов и книг, но смешно ли будет нам (а особенно бухгалтерии), если нейросеть начнет галлюцинировать при распознавании платёжных реквизитов или суммы НДС? И чем выше степень развития сетей — тем менее заметными будут становиться такие ошибки.

В прошлом году на одной из ключевых конференций в области анализа и распознавания документов — ICDAR — учёные традиционно задались вопросом о будущем OCR. И сошлись во мнении, что OCR нисколько не устарела, благополучно развивается и остается наиболее надежным инструментом распознавания. Обеспечить требования консистентности (и ещё всякого такого) информации, извлекаемой из изображения, все равно сможет только старый добрый OCR и прочие детерминированные алгоритмы. И именно их разработкой (и доведением до совершенства) мы и занимаемся.

Вернёмся к библиотеке Smart Document Engine. Как уже говорилось выше, гибкие формы на то и гибкие, что исключительно геометрией на них не обойдёшься — вопрос местонахождения полей решается «на лету». На процесс взаимодействия с библиотекой это влияет в самом конце, на моменте работы с результатом. Перейдем к знакомству с интерфейсом на примере всё того же встраивания в андроид.

Встраивание

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

Логическая и физическая части документа разбираются отдельно, так как в некоторых случаях геометрия вообще не нужна (если результат распознавания документа дальше идёт в базу данных):

Как правило, результат распознавания представляют в виде json-объекта, но для наглядности лучше всего пользоваться html — особенно в случае, когда логические и физические поля имеют больше одного соответствия. Вот простенький генератор html на основе документа:

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

Конечно, помимо андроида встроить распознавание и организовать удобные представление документа (при необходимости) можно и на любой другой платформе, однако с трендом на создание банковских офисов нового поколения и развития курьерской сети автоматизация ввода документов с помощью средненьких мобильных устройств на Андроиде становятся актуальной задачей.

На этом мы не заканчиваем, ждите новых статей!

Разбираемся, какие основные задачи закрывает проджект и нужно ли ему знать программирование и уметь кодить. В этом нам поможет Артем Харченков — автор Telegram-канала «IT Инсайты», где он делится мыслями об IT и тимлидстве. Артем руководит командой 40+ человек более 4 лет, управляет департаментами разработки, тестирования, аналитики и DevOps, является спикером TeamLead Conf и участником подкастов и ведущим вебинаров. Был инженером внедрения и Java-программистом.

Какие главные задачи у PM в айти

Менеджер проекта (или Project Manager, PM) — это функциональный руководитель команды, которая работает над определенным проектом. PM отвечает за то, кто и что в команде делает, чтобы достичь поставленных целей.

Основная задача менеджера проектов в IT — контролировать, чтобы вверенный ему проект был выполнен в срок, с должным качеством и утверждённым составом работ.

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

До работы над проектом обычно составляется план-график, и PM следит за тем, чтобы команда ему следовала. Мотивация команды и поддержание командного духа — также одни из базовых функций PM. Важно понимать, что хороший PM должен не только адекватно оценивать ситуацию на проекте и задавать направление, но и уметь принимать меры, если что-то идёт не так.

Нужно ли в принципе проджекту учить программирование или он его должен знать изначально

Если говорить о проектах разработки ПО, то для того, чтобы стать в них хорошим PM, очень полезно иметь опыт работы в одной из ролей проектной команды. Так как программисты — основная движущая сила проекта, опыт работы в этой роли даёт преимущество в понимании процессов разработки. Это помогает общаться с ними «на одном языке».

Однако я знаю хороших PM, которые выросли из тестировщиков или аналитиков. Одно можно сказать точно: чтобы хорошо руководить командой, следует понимать, по каким правилам она работает, а для этого нужно побывать в ней «изнутри».

Если вы стали PM без технического бэкграунда, будет крайне полезно изучить, какую работу делает каждая из командных ролей, и начать лучше, конечно, с роли разработчика. Без понимания выполняемых членами команды функций PM не сможет принимать адекватные решения и расставлять приоритеты.

Какие базовые штуки из программирования нужно знать PM-у, чтобы не теряться в разговорах с кодерами

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

При правильном распределении обязанностей на проекте PM’у вообще не требуется читать код: ни настоящий, ни псевдо. Его задача — организация процесса, а не техническая реализация.

Как знание кода помогает адекватно оценивать дедлайны

Если PM имеет опыт работы программистом, он понимает, какие задачи в разработке являются сложными, а какие — простыми. Это даёт преимущества в прогнозировании сроков: он может самостоятельно примерно оценить время на реализацию функции или, если оценка другого программиста ему кажется завышенной, уточнить причины расхождения в прогнозах. В таких обсуждениях часто удаётся найти оптимальное решение: выбрать более простой способ реализации, который сократит сроки, но при этом покроет основные потребности заказчика.

При этом анализ узких мест в коде — не задача PM’а, для этого на проекте обычно есть архитектор, техлид или старший разработчик. Однако PM должен учитывать известные технические риски при планировании, чтобы избежать срыва сроков.

Про технические штуки: что нужно и не нужно знать

Стоит ли вникать в Git

Git — важный инструмент для командной работы программистов, он уже стал стандартом в современных проектах. Как и в других технических инструментах, PM не обязан знать команды push, fetch или merge и уметь ими пользоваться, но должен иметь общее понимание базовых вещей (например, «ветка», «репозиторий», «merge request», «commit»). Без этих знаний PM не сможет эффективно управлять процессом доставки функций и выпуска релизов, выявлять их узкие места и принимать взвешенные решения по устранению проблем.

Нужно ли знать, чем монолит отличается от микросервисов

Понимание этой разницы — сейчас базовое требование в IT. Я рекомендую изучить плюсы и минусы обоих подходов к построению систем. Хорошо, что современные ИИ-помощники позволяют разобраться в этом за пару часов: они опишут всё подробно «на пальцах» и с примерами.

Должен ли PM знать подходы к разработке, например, CI/CD или TDD

PM должен понимать смысл этих аббревиатур, цели их применения командой и пользу, которую они приносят.

Как понимание тестов (типа юнит-тестов) спасает при проверке качества

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

Базы данных — это важно для PM-ов или только для разработчиков

Важность понимания принципов работы баз данных для PM зависит от предметной области проекта. Например, при разработке стандартной CRM-системы база данных — лишь один из модулей продукта. В этом случае PM должен понимать только то, что это за база, какие данные в ней хранятся и обрабатываются.

Если же проект связан с созданием ПО для работы с базами данных (например, клиента для БД или системы оптимизации SQL-запросов), потребуется гораздо более глубокое знание их принципов работы.

Веб, мобилки, данные — отличается ли набор знаний для PM-а в этих стеках

В общем случае — нет. Различия между этими типами проектов в основном технические, но во всех случаях над достижением цели работает команда с распределёнными ролями. Навыки PM в первую очередь — это способность её мотивировать, выделять приоритеты, проводить эффективные встречи и обеспечивать выполнение задач в срок. Технические инструменты PM (например, таск-трекеры, диаграммы Ганта или покер-планирование) могут различаться, но они не связаны напрямую с инструментами разработки, аналитики или тестирования.

Конечно, одинаковых проектов не бывает: каждый имеет технические и организационные особенности. Однако в любом из них ключевая цель — выполнить определённый объём работ в срок с должным качеством. Именно умение достигатьдост этой цели — главный критерий успешности PM.

Узнаем, что собой представляет технология, как формируются AJAX запросы, как работает инструмент, каковы его преимущества, недостатки и ограничения.

Основные компоненты AJAX

Термин AJAX используется в программировании с 2005 года, хотя подобные способы обмена данными применялись и ранее. Это универсальное решение для веб-приложений, которое объединяет несколько компонентов. Именно благодаря AJAX реализованы такие проекты, как современные соцсети, Google Maps, Gmail, Google Docs и многие другие.

Основная задача AJAX — запросы к серверу в обход перезагрузки страницы. Это уменьшает время отклика и позволяет веб-приложению работать в интерактивном режиме. Несмотря на присутствие в названии отсылки к XML, использовать этот язык разметки не обязательно.

Технология реализуется через JavaScript — происходит заданный скриптом асинхронный обмен данными между сервером и браузером. Именно на JS создаются запросы для коммуникации с сервером и динамического изменения страницы.

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

Код на JavaScript — не единственный компонент AJAX. В него также входят форматы хранения данных XML или JSON. При этом JSON для отправки запросов AJAX используется чаще, поскольку код у этого формата короче, что существенно упрощает передачу данных.

Важнейший компонент технологии — объект XMLHttpRequest, который отвечает за все запросы AJAX. Этот API предоставляет клиенту полноценный функционал для взаимного обмена данными с сервером. Раньше XHR поддерживали не все браузеры — разработчикам приходилось дополнительно подключать библиотеку jQuery с встроенным объектом. Сейчас большинство популярных браузеров, включая Chrome и Firefox, работают с XMLHttpRequest напрямую.

Примечание. В современных программных веб-продуктах вместо XHR нередко используют Fetch AP, но говорить о массовом тренде преждевременно.

Передача данных выполняется через стандартный протокол взаимодействия клиента и сервера HTTP. Браузер инициирует запрос, получает в ответ HTML-страницу, либо сообщение об ошибке (если в запросе есть неточности). Используются стандартные методы получения данных — GET и POST. Первый (GET) применяется при получении данных от сервера, второй (POST) используется для отправки данных на сервер в теле HTTP-запроса.

Благодаря способности AJAX работать с разными форматами, типами данных и серверными API, эта методика универсальна. Асинхронный обмен позволяет веб-приложениям быстро загружаться, плавно работать и не перезагружаться после каждого запроса пользователя к серверу. Это особенно актуально для приложений, требующих постоянного взаимодействия с сетевым устройством — социальных сетей, онлайн-магазинов, браузерных версий мессенджеров.

Как работает AJAX

Магия асинхронных запросов AJAX базируется на взаимодействии с DOM-объектами браузерной страницы. Процесс выглядит следующим образом:

1. С помощью JavaScript браузер отправляет HTTP-запрос на сервер, где происходит обработка данных и отправка ответа. Чтобы отправить запрос, потребуется создать объект XMLHttpRequest — без него отправлять запросы и получать ответы без перезагрузки не получится.
2. При этом запрос необходимо настроить — указать метод GET/POST, URL и перейти на асинхронный режим работы.
3. Сервер возвращает данные, с которыми начинает работать JavaScript. Когда браузер принимает исходный код страницы, он выстраивает множество виртуальных элементов на базе этого кода — сюда входят заголовки, изображения, текст, ссылки и прочее.
4. При этом к каждому компоненту виртуальной модели можно обращаться отдельно с целью изменить его свойства или содержание. JavaScript позволяет поменять фон страницы, изменить заголовок и внести другие изменения, не перегружая страницу.

Простой пример запроса AJAX выглядит следующим образом (используется метод получения данных GET):

В этом примере мы создаем объект XMLHttpRequest, настраиваем запрос, обрабатываем ответ и данные, отправляем запрос на сервер. Данные выводятся в консоль без перезагрузки страницы — обновляется только нужный элемент интерфейса.

В следующем примере показан код для отправки формы с использованием запроса AJAX:

С помощью этого кода пользователь отправляет данные формы на сервер и получает ответ без перезагрузки страницы. В браузере запускается скрипт, привязанный к кнопке «Отправить». Все процессы происходят внутри скрипта — новая информация встроена в уже открытую страницу.

Отладка AJAX-запросов

Для эффективной разработки и поддержки приложений программистам важно научиться отлаживать и тестировать запросы AJAX. Для этого необходимы встроенные инструменты браузеров Chrome, Firefox, Edge и других.

Эти инструменты позволяют:

• просматривать отправленные на сервер запросы во вкладке Network;
• проверять атрибуты запросов/ответов и их содержимое;
• следить за временем выполнения отправленных запросов, выявлять узкие места и оптимизировать процессы.

Для тестирования запросов полезно создавать фейковые API или проверять работу реальных интерфейсов вне контакта браузера с помощью библиотек MSW или Postman.

Прогерам будут полезны ценные советы по оптимизации процессов при работе с запросами:

• Используйте кэширование, чтобы уменьшить количество запросов. Это снижает нагрузку на сервер и повышает производительность.
• Применяете сжатие данных для снижения объема отправляемой информации. Это ускоряет процесс передачи и обработки данных.
• Всегда обрабатывайте ошибки для улучшения пользовательского опыта. Лучше заранее предусмотреть все варианты, чтобы снизить риск возможных проблем при использовании приложения.

Преимущества AJAX

Перечислим основные плюсы технологии:

• Обновление данных без необходимости перезагружать страницу. Это улучшает опыт пользователей и делает взаимодействие с приложением более плавным и быстрым. Юзерам гораздо удобнее видеть обновление на той же странице, чем загружать новую.
• Уменьшение трафика. Поскольку браузер получает от сервера не всю страницу полностью, а только ограниченную запросом информацию, тратится меньше ресурсов на передачу данных.
• Снижение нагрузки на сервер. Если приложение открывает страницы «на лету», достаточно один раз прогрузить стандартные элементы (шапку, меню, подвал), а остальные части загружать по необходимости.
• Быстрота и отзывчивость приложений. Чем меньше данных в запросе AJAX, тем быстрее придет ответ от сервера. В современных продуктах скорость и удобство — ключевые конкурентные преимущества.
• Экономия ресурсов. Безлимитный интернет есть не у всех и не везде, а запросы AJAX используют ресурсы в минимальном режиме.

Необходимо также понимать, что технология не универсальна и подходит не для всех ситуаций и приложений.

Недостатки AJAX

В числе основных минусов AJAX:

• Потенциальные проблемы с SEO-контентом. Содержание страниц, которое подгружается с помощью AJAX, часто недоступно для поисковиков, что негативно сказывается на индексации. Поисковые системы видят исходный ход, но не данные с серверов. Это может быть проблемой для сайтов, которые нуждаются в привлечении пользователей. Для сеошников работа с сайтами на AJAX — головная боль.
• Кэширование. Динамическое содержание может создать сложности с кэшированием, что приводит к загрузке неактуальных данных.
• Зависимость от JavaScript. Пользователь может отключить JavaScript, что ограничит функциональность сайта. Данные не смогут прийти с сервера, интерактивного обновления не получится.
• Усложнение проекта. Работа с запросами AJAX требует от разработчиков определенной квалификации. Они должны предвидеть различные внештатные ситуации, связанные с асинхронными запросами, и заранее прописать скрипты на такие случаи. Потребуется также продумать бэкенд — ответы сервера на различные запросы.

При нестабильной связи AJAX может не получить ответа от сервера либо не отправить запрос. Такая ситуация нарушает логику загрузки страницы — ее придется все-таки перезагружать и начинать все с нуля.

Где используется AJAX

Технологию используют для улучшения пользовательского опыта при работе с сайтами и веб-приложениями. AJAX-запросы решают множество подзадач:

• Динамическое обновление. С помощью AJAX обновляются отдельные элементы страниц — таблицы, списки, графики. Это особенно удобно на сайтах, где применяются фильтры — например, на страницах онлайн-магазинов.
• Автозаполнение и поиск. AJAX используется для мгновенной выдачи результатов поиска. Юзер только начинает вводить текст в поисковую строку и уже видит релевантные варианты. Это удобно для формирования точных и подробных поисковых запросов.
• Отправка формы. Чтобы отправить данные заполненных форм, пользователю не нужно ждать обновления, что делает работу более плавной. Например, можно залогиниться после просмотра сайта, оставшись на той же странице.
• Загрузка данных для конкретного пользователя. В соцсетях или на сайтах с интерактивными опциями новые сообщения, уведомления и комментарии подгружаются без обновления страницы.
• Динамические интерфейсы. Этот процесс вы можете наглядно наблюдать на Гугл-картах и в подобных приложениях — по мере прокрутки подгружаются новые части территории. Аналогичная опция реализована на сайтах с интерактивными прогулками по гостиницам, музеям и другим локациям.

Иными словами, AJAX-запросы используются везде, где требуются обновления содержания без перезагрузки: чтобы получить список новых сообщений в чате или в общей ленте; подгрузить позиции на витрине товаров; увидеть рекламные баннеры и т.д.. В Ютубе на этой технологии основано сворачивание видео в компактный плеер в углу.

AJAX — незаменимый инструмент для разработки динамических интерфейсов и улучшения пользовательского опыта. Механизм основан на асинхронности работы браузера и сервера. При нормальной скорости интернета данные передаются мгновенно, так что пользователям даже не приходится ждать. При этом AJAX универсален и может работать с разными форматами данных и серверными API.

Данный шаг направлен на поддержку моддеров и сохранение исторического наследия культовых стратегий в реальном времени.

В открытый доступ выложены исходные коды:

• Command & Conquer: Tiberian Dawn
• Command & Conquer: Red Alert
• Command & Conquer: Renegade
• Command & Conquer: Generals и дополнение Zero Hour

Поддержка моддеров и новые возможности

EA также добавила поддержку Steam Workshop для нескольких игр серии, включая Renegade, Generals, Zero Hour, Tiberium Wars, Kane’s Wrath и Tiberian Twilight. Это упрощает создание и распространение пользовательских модов.

Для поддержки моддеров EA также выпустила «C&C Modding Support» – пакет с исходными файлами XML, схемами, скриптами, шейдерами и картами для игр на движке SAGE.

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

Кто стоял за открытием исходников?

Инициативу по публикации исходного кода возглавили:

• Брайан Барнс – технический директор EA,
• Джим Веселла – продюсер Respawn,
• Люк Фенан – давний участник сообщества C&C.

Благодаря их усилиям удалось восстановить и опубликовать исходники, что стало значимым вкладом в развитие моддинга и сохранение классики RTS.

Что такое JSON

JSON или JavaScript Object Notation — формат для обмена данными. Его используют в веб-разработке, чтобы передать числовую информацию от клиента к серверу и наоборот. По сути это просто строка, но с нюансами.

JSON — стандарт в веб-разработке, так как его текстовая структура легко читается как человеком, так и компьютером. Давайте посмотрим, из чего он может состоять:

• Объекты — пары “ключ-значение” в фигурных скобках. Выглядят так же, как обычные JS-объекты;
• Массивы — упорядоченные значения. Заключаются в квадратные скобки и отделяются запятой;
• Ключи — строки, которые обязательно в двойных кавычках. Одинарные не подойдут;
• Значения — могут быть строками в двойных кавычках, числами, логическими значениями, массивами, объектами или null.

Мы не зря упоминаем двойные кавычки. Очень важно следить за ними, иначе сервер или ваш сайт не смогут обработать JSON.

Пример JSON-документа:

В этом примере объект содержит четыре ключа:

• name — строка,
• type — строка,
• topics — массив строк,
• published — логическое значение, true.

Этот JSON описывает воображаемую статью, у которой есть темы, название и статус публикации.

Зачем нужен JSON, если есть XML?

До JSON разработчики использовали XML. Вот основные отличия:

Давайте разберём все пункты и посмотрим, в чём же конкретно хорош JSON.

Синтаксис

JSON

Выглядит как обычный JavaScript-объект.

Пример:

Мы создали объект с двумя ключами. Имя –– John, возраст –– 30. Это упрощённый вариант хранения данных о пользователе. Также можно добавить почту, ник, город и так далее.

XML

XML или (Extensible Markup Language) –– посложнее, так как использует закрывающиеся теги. Это делает его визуально более «шумным» и трудным для восприятия. Особенно если XML-данных много.

Размер данных

JSON

JSON компактнее, в нём нет лишних тегов и атрибутов. Он лучше подходит для веба, так как важна минимизация. Чем данные легче, тем быстрее работает сайт.

XML

XML объемнее, потому что каждый элемент должен быть обёрнут в открывающий, а потом закрывающий тег.

Легкость парсинга

JSON

JSON легко парсить. В JavaScript достаточно использовать JSON.parse(), чтобы преобразовать JSON-строку в JS-объект.

Пример:

Здесь мы поместили JSON-строку в переменную и затем распарсили её в другую переменную с помощью функции JSON.parse().

XML

XML-файлы могут быть большими, с множеством вложенных тегов: чтобы распарсить такие данные, нужно много времени и ресурсов.

Пример на JavaScript:

Что здесь происходит:

1. Создаем строку, которую хотим превратить в XML. Она содержит элемент с вложенными элементами;
2. Используем объект DOMParser. Он превращает текстовые строки в XML-документы;
3. Метод parseFromString() выполняет это преобразование. После этого js работает с переменной через DOM-методы;
4. Используем метод getElementsByTagName(), чтобы получить значение элемента . Он возвращает массив элементов с указанным тегом;
5. Указываем индекс [0] для выбора первого элемента, а затем получаем его текстовое содержимое через childNodes[0].nodeValue.

Разница очевидна:

• Для JSON мы можем сразу преобразовать строку в объект с помощью JSON.parse();
• Для XML требуется больше шагов: разбор строки в документ и использование методов DOM для извлечения данных.

Читаемость

JSON

JSON легко читать, потому что его структура похожа на JavaScript-объект. Он не требует лишних символов и тегов, поэтому визуально лаконичен и прост.

XML

XML выглядит сложнее. Теги для описания структуры делают документ более громоздким и менее читаемым. Особенно если в файле много вложенных элементов.

Создаём и парсим JSON

JSON-документы можно создать вручную. Главное, надо соблюдать синтаксические правила:

• Использовать двойные кавычки для строк;
• Разделять ключи и значения двоеточием, как и в JS-объектах;
• Ставить запятые между ключами.

А можно использовать конвертер. Вы ему JS-объект, а он из него –– JSON.

В разных языках –– разные инструменты для работы с JSON. Разработчики используют встроенные средства языков программирования или сторонние библиотеки:

• JavaScript: Методы JSON.stringify() и JSON.parse();
• Python: Модуль json для сериализации и десериализации;
• PHP: Функции json_encode() и json_decode();
• Node.js: Встроенные методы для работы с JSON в модуле fs.

Работа с JSON в Python

Что тут происходит:

1. Импортируем json. Это встроенная библиотека Python. Она работает с данными в формате JSON;
2. Создаём данные для сериализации –– Python-словарь data, который содержит пары ключ-значение. Не пугайтесь нового слова «сериализация». Это всё то же преобразование одного формата в другой;
3. Используем метод json.dumps() для преобразования Python-объекта в строку в формате JSON. Результатом будет строка, которую можно передать серверу, сохранить в файл или обработать в другой программе;
4. Десериализириуем данные с помощью метода json.loads(). Он преобразует JSON-строку обратно в Python-объект;
5. Выводим десериализованные данные в консоль. В данном случае это словарь parsed_data, который будет точно таким же, как и исходный словарь data.

Работа с JavaScript

Методы JSON.stringify() и JSON.parse() позволяют преобразовывать данные из объекта в JSON-строку и обратно.

Пример:

Метод fetch() используется для отправки HTTP-запросов с JSON-данными:

Что здесь происходит:

• Мы указываем, куда нужно сделать запрос и что нужно передать серверу. Посылка –– это значение в ключе body. Если не обернуть объект с данными в JSON.stringify(), то запрос упадёт. Так как этот метод превращает JS-объект в JSON-строку. Сервер умеет читать JSON, но не умеет работать с JS-объектами;
• На предпоследней строке мы получаем ответ от сервера. А затем обязательно переводим его обратно, в удобоваримый для JS код.

Работа с JSON на сервере

JSON незаменим в бэкэнде. Сервер присылает данные через REST API в JSON. Поэтому в предыдущем блоке мы использовали на ответе метод .json(). Без него данные останутся обычной JSON-строкой.

Разберём примеры на разных языках.

Пример реализации REST API на Node.js

Здесь мы создаём приложение на основе Express. Оно слушает POST-запросы на маршруте /data и возвращает ответ в формате JSON с сообщением о том, что данные получены.

Для работы с JSON на сервере используем встроенную функцию express.json(), которая парсит данные, и метод res.json(), чтобы отправить ответ в формате JSON.

Пример работы JSON в python-фреймворке Flask

Что делаем:

1. Импортируем необходимые библиотеки: Flask, request, jsonify для создания нашего веб-приложения и обработки JSON-строк;
2. Создаем приложение через экземпляр Flask;
3. Определяем маршрут /data и указываем, что функция handle_data() будет обрабатывать по этому маршруту POST-запросы;
4. Извлекаем JSON-данные из запроса внутри функции. Получаем и преобразуем данные из тела запроса в JSON с помощью request.get_json();
5. Отправляем JSON-ответ. Возвращаем клиенту JSON-ответ, содержащий полученные данные. Либо, если переменная data пуста, отправляем ошибку и 400 статус. И обязательно отлавливаем ошибки с помощью try-except;
6. Запускаем приложение. Приложение запускается на сервере и слушает входящие запросы.

Что не так с JSON

За простотой JSON скрываются ловушки, попадать в которые лучше не надо. Малейшая ошибка — и данные становятся нечитаемыми, а приложение падает. Разберём эти ловушки:

Неправильная структура

Забудете закрыть скобку, добавите не ту кавычку или поставите запятую в конце массива — и всё. Браузер или сервер выдадут ошибку. А если JSON создается динамически, найти проблему будет сложно.

Пример ошибки:

В этом примере после крайнего элемента массива стоит лишняя запятая. Исправленный вариант:

Большие объемы данных

JSON не предназначен для хранения огромных массивов данных. Обрабатывать большие файлы в браузере –– опасно для производительности. Ваш сайт может начать тормозить или вовсе зависнуть.

Неэкранированные символы

Забыли экранировать кавычку в строке? Получите ошибку. JSON требует строго соблюдать правила синтаксиса, иначе парсинг провалится.

Пример ошибки:

Здесь у нас дублирование. Нельзя помещать двойные кавычки внутрь таких же двойных кавычек:

Исправленный вариант:

Уязвимая безопасность

Если данные не проверяются, JSON может стать источником XSS-атак или привести к раскрытию конфиденциальной информации.

Пример ошибки:

Пользователь может отправить через поле ввода вредоносные данные. И получится вот такая история:

Решение: обязательно проверяйте входящие данные. Можно заменить опасные символы безопасными:

И уже эту строку отправить на сервер.

Как избежать проблем с JSON?

Чтобы работать с JSON безопасно и эффективно:

• Используйте валидаторы. Перед передачей данных обязательно проверяйте JSON на синтаксические ошибки;
• Сжимайте данные. Уменьшайте размер JSON, удаляя лишние пробелы и символы, чтобы оптимизировать передачу и обработку;
• Не доверяйте входящим данным. Проверяйте и фильтруйте всё, что приходит от клиента или сторонних API;
• Ограничивайте глубину вложенности. Глубокая структура JSON может перегрузить обработчик и вызвать зависание.

Валидаторы JSON

Перед отправкой проверьте свой JSON. Для этого можно использовать онлайн-валидаторы. Например, https://jsonlint.com. Как он работает: вы прописываете вашу строку, а валидатор проверяет, нет ли в ней ошибок.

Минификация JSON

Для уменьшения размера JSON-строку можно минифицировать. Удалить пробелы и переносы строк. Пример минификации в Python:

Обработка ошибок при работе с JSON

Ошибки часто возникают из-за неправильного формата данных. Всех опасных мест не избежать. Но можно подстелить соломку.

Вот так обрабатываются возможные ошибки с JSON:

Что тут происходит:

1. Получаем данные из localStorage: Используется метод localStorage.getItem(), чтобы извлечь данные по указанному ключу key;
2. Проверяем на наличие данных: Если данные отсутствуют –– null, выбрасывается ошибка с помощью throw;
3. Парсим данные: Если данные есть, они парсятся через JSON.parse(). И на выходе получается JS-объект;
4. Обрабатываем ошибки: В блоке catch ловятся все ошибки. Затем их можно обработать и отобразить пользователю в интерфейсе.

Теперь даже если в LocalStorage не лежат нужные данные, приложение не упадёт.

В веб разработке без JSON никуда. Он лёгкий и гибкий. Но чтобы использовать эти преимущества, нужно научиться с ним взаимодействовать.

Для этого просто следуйте нашим правилам. Проверяйте свои JSON-строки, обрабатывайте ошибки и тестируйте приложение на корнер-кейсы. Тогда ваши сайты и приложения будут в безопасности. 🙂

В статье детально разобрали подходы к реализации HTTP-запросов на практике.

Общие понятия HTTP-запросов

HTTP (HyperText Transfer Protocol) определяет правила обмена данными между клиентом и сервером. Клиент, браузер или приложение отправляют запрос серверу, который обрабатывает его и возвращает ответ.

HTTP-запрос состоит из нескольких компонентов:

Метод

Обозначает действие, которое клиент хочет выполнить. Например, метод GET используется для запроса данных с сервера, а POST — для отправки данных на сервер.

URL

Определяет адрес ресурса, к которому обращается клиент. Он включает в себя доменное имя и путь к конкретному ресурсу на сервере.

Заголовки

Содержат дополнительную информацию о запросе. Могут включать данные о типе контента, формате принятого ответа и других параметрах, необходимых для обработки запроса.

Тело

Используется при отправке сведений на сервер. В методе POST тело содержит данные формы или другие данные, которые необходимо передать. При методе GET тело обычно отсутствует, так как данные передаются в URL.

Статус-коды ответа

После обработки запроса сервер возвращает ответ со статус-кодом. Он сообщает клиенту о результате обработки запроса.

Категории статус-кодов:

• Информационные 1xx: указывают, что запрос принят и продолжается обработка;
• Успешно 2xx: подтверждают успешную обработку запроса;
• Перенаправления 3xx: информируют о совершении редиректа;
• Ошибки клиента 4xx: указывают на проблемы со стороны клиента;
• Ошибки сервера 5xx: указывают на проблемы со стороны сервера.

Статус-коды помогают клиенту понять результат запроса и, при необходимости, предпринять действия — обновить страницу, согласиться на перенаправление и т. д.

Основные методы HTTP-запросов

GET и POST используются для получения и отправки данных соответственно. Каждый метод имеет свои особенности.

GET — получение данных

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

При использовании GET-запроса параметры передаются через строку запроса в URL: можно закэшировать запросы и делать их повторно без отправки данных.

Повторное выполнение запроса не изменит состояние сервера. Это важно для безопасности и эффективности в сетевых операциях. Например, при обновлении страницы браузер отправляет GET-запрос, чтобы загрузить актуальное содержимое.

Ограничения метода GET связаны с объемом передаваемых данных. Поскольку параметры передаются в URL, есть ограничение на длину строки. Поэтому метод GET не подходит для передачи больших объемов данных или конфиденциальной информации, т. к. содержимое отображается в адресной строке.

POST — отправка данных

Метод используется для отправки данных на сервер, чтобы создать или обновить ресурсы. В отличие от GET, данные передаются в теле запроса. Можно передавать большие объемы информации и делать это более безопасно, потому что данные не отображаются в URL.

Повторная отправка POST-запроса может привести к созданию нескольких одинаковых ресурсов или повторному выполнению операции. Обрабатывать такие запросы нужно с особой осторожностью.

POST используется при отправке форм на веб-сайтах, загрузке файлов, в API-запросах. Он поддерживает передачу сложных структур данных, включая JSON или XML.

Другие методы HTTP-запросов

Помимо GET и POST есть дополнительные методы для гибкого управления ресурсами. К ним относятся PUT, DELETE, PATCH, HEAD и OPTIONS.

PUT — обновление данных

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

Клиент отправляет запрос с полным представлением ресурса, которое сервер должен сохранить. Если ресурс по указанному URI не существует, сервер создаст его.

DELETE — удаление данных

Используется для удаления ресурса по URI. При успешной обработке запроса веб-страница становится недоступной.

Как и PUT, метод DELETE идемпотентный: повторные запросы удаления не приведут к ошибке, хотя сервер может сообщить, что ресурс уже недоступен.

PATCH — частичное обновление

Предназначен для частичного изменения ресурса.

Вместо отправки полного представления, как в случае с PUT, клиент отправляет только те данные, которые необходимо обновить.

HEAD — запрос заголовков без тела

Необходим для получения метаданных без передачи содержимого.

Применяется для проверки ресурса, определения его размера или времени последнего изменения без необходимости загружать весь ресурс.

OPTIONS — получение информации о поддерживаемых методах

Используется для выявления возможностей сервера или проверки поддерживаемых методов.

Клиент может узнать, какие HTTP-методы доступны для данного URI, а также получить информацию о поддерживаемых заголовках и других параметрах.

Различия между GET и POST

Несмотря на то, что оба метода используются для отправки запросов, они имеют существенные различия в способах передачи данных, кэшировании и безопасности.

URL vs. тело запроса

GET передает данные через строку URL, добавляя параметры запроса после знака вопроса “?”. Параметры представляют собой пары «ключ=значение», разделенные амперсандом “&”.

POST передает данные в теле запроса, отделенном от заголовков пустой строкой. В ней можно передавать больше данных и использовать форматы типа application/x-www-form-urlencoded или multipart/form-data.

Кэширование и безопасность

GET подвержен кэшированию браузерами и промежуточными серверами. Он снижает нагрузку на сервер и ускоряет загрузку страниц, повторно используя ранее полученные ответы. Однако кэширование становится причиной тогда, когда клиент получает устаревшие данные, если ресурс на сервере уже был обновлен.

POST обычно не кэшируется, поскольку предполагается, что каждый запрос может изменять состояние сервера или создавать новые данные. Браузеры и прокси-серверы по умолчанию не сохраняют ответы на POST-запросы в кэше.

С точки зрения безопасности, GET менее предпочтителен для передачи конфиденциальной информации. Данные, переданные через URL, открыты для посторонних лиц, сохраняются в истории браузера и логах сервера.

POST дает большую конфиденциальность, так как данные передаются в теле запроса и не отображаются в адресной строке.

Сами по себе методы GET и POST не спасают сообщение от кражи. При передаче чувствительной информации необходимо использовать соединение HTTPS, которое шифрует данные и защищает от перехвата злоумышленниками.

Оба метода уязвимы к атаке CSRF. Поскольку GET-запросы можно совершать простым переходом по ссылке или загрузкой изображения, атаки через GET встречаются чаще. Для защиты от CSRF рекомендуется использовать уникальные токены и проверять происхождение запросов на сервере.

Работа с HTTP-запросами на практике

Рассмотрим реализацию HTTP-запросов в JavaScript с использованием fetch и axios, тестирование запросов через Postman и применение HTTP в бекенд-разработке на примерах Node.js, Python и PHP.

JavaScript (fetch, axios)

Fetch — встроенная функция JS. Она отправляет HTTP-запросы и обрабатывает ответы.

Пример выполнения GET-запроса:

Здесь выполняется запрос к URL, затем ответ преобразуется в формат JSON.

Для отправки POST-запроса с передачей данных в теле используется следующий синтаксис:

В теле запроса передаются данные в формате JSON, а заголовок Content-Type сообщает серверу о типе данных.

Использование axios

Axios — популярная библиотека для выполнения HTTP-запросов, поддерживающая как браузерную, так и серверную среду.

Пример выполнения GET-запроса:

Для отправки POST-запроса с данными:

Axios автоматически преобразует объекты JavaScript в JSON и устанавливает заголовки, что упрощает работу с запросами.

Тестирование через Postman

Postman — инструмент для разработки и тестирования API. Для его использования необходимо установить приложение, создать новый запрос, указать метод и URL.

При тестировании GET-запроса в Postman вводится URL и при необходимости добавляются параметры. После отправки запроса интерфейс показывает заголовки и тело ответа, что помогает в отладке и анализе данных.

Для POST-запросов в Postman можно указать тело запроса в форматах form-data, x-www-form-urlencoded, raw и других. Это позволяет отправлять сложные структуры данных и файлы, имитируя работу реальных приложений.

Postman также поддерживает сохранение коллекций запросов, управление переменными среды и написание скриптов для автоматизации тестирования.

Использование HTTP в backend

В Node.js для создания веб-серверов и обработки HTTP-запросов обычно используется фреймворк Express:

Этот сервер обрабатывает GET и POST-запросы по пути /users. Можно получать список пользователей и создавать новых.

Python

В Python популярным фреймворком для веб-разработки выступает Flask:

С помощью Flask создается сервер, обрабатывающий HTTP-запросы и возвращающий данные в формате JSON.

PHP

В PHP с фреймворком Laravel можно реализовать обработку HTTP-запросов следующим образом:

Работа с HTTP в backend-приложениях состоит не только в приеме запросов, но и в отправке их к другим сервисам. В языках для веб-разработки есть библиотеки для выполнения исходящих HTTP-запросов:

• axios для Node.js,
• requests для Python,
• Guzzle для PHP.

Теперь ваша очередь! Попробуйте применить полученные знания на практике. Создайте простое приложение, использующее HTTP-запросы, или протестируйте API с помощью Postman.

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

Если вы хотите научиться работать с этими форматами и эффективно обрабатывать данные, рекомендуем пройти курс по Python.

JSON (JavaScript Object Notation)

JSON основан на JavaScript, но его понимают и другие языки программирования. Данный формат проще читать, он меньше весит, быстрее передается и совместим с разными платформами.

JSON состоит из объектов, ключей и значений. При этом файл сам является основным объектом, внутри которого могут быть другие объекты.

Перед объектом ставятся фигурные скобки {}. Далее идет имя ключа в кавычках “”, двоеточие и значение.

Значения могут содержать числа, строки, массивы. Также бывают пустые и булевые значения.

Пример синтаксиса JSON:

XML (eXtensible Markup Language)

Стандартный XML уступает JSON в читабельности, скорости передачи и кроссплатформенной совместимости. Но он поддерживает больше типов данных, поэтому хорошо подходит для сложных строгих структур.

Его код начинается с пролога. Это запись, в которой мы указываем версию и кодировку:

Далее идет структура из элементов, внутри которых хранится наша информация с разными типами данных. Этот принцип напоминает устройство HTM кода.

Элементы состоят из тегов — они бывают открывающими и закрывающими. Открывающий тег состоит из знака меньше “<”, имени и знака больше “>”.

Аналогично с закрывающим тегом. Но к нему добавляем слэш “/” после знака меньше “<”. Вот так:

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

Для открывающих тегов есть возможность прописывать атрибуты — они позволяют указывать дополнительную информацию для элементов. Делается это вот так:

Здесь мы написали атрибут gender со значением “female”

При написании кода мы должны заключить все элементы в один главный элемент. Его называют корневым:

В этом примере <person> корневой элемент.

Библиотеки python для работы с JSON и XML

Существует много библиотек для работы с JSON и XML. Ниже перечислены основные из них.

Библиотеки для работы с JSON

json

• Не нужно устанавливать, встроена по умолчанию.
• Может парсить из строк и файлов.
• Способна конвертировать объекты в JSON-строки.

SimpleJSON

• Может парсить из строк и файлов.
• Способна создавать JSON-строки из объектов.
• Предоставляет более гибкие опции кодирования и декодирования по сравнению с встроенной json.

ujson

• Может парсить из строк и файлов.
• Способна конвертировать объекты в JSON-строки.
• Отличается высокой скоростью работы благодаря реализации на C.

orjson

• Может парсить из строк и файлов.
• Способна создавать JSON-строки из объектов.
• Производительная благодаря реализации на Rust.
• Поддерживает только Python версии 3.6 и выше.
  

ijson

• Может парсить из строк и файлов.
• Экономит память за счет потоковой обработки данных.

jsonschema

• Специализируется на валидации.
• Поддерживает различные версии спецификации JSON Schema.

cerberus

• Специализируется на валидации.
• Поддерживает валидацию сложных вложенных структур и поддерживает пользовательские правила валидации.

Библиотеки для работы с XML

xml.etree.ElementTree

• Встроена по умолчанию.
• Может парсить из строки и файлов.
• Способна создавать и редактировать XML-строки и файлы.

lxml

• Может парсить из строки и файлов.
• Способна создавать и редактировать XML-строки и файлы.
• Поддерживает валидацию.
• Обеспечивает высокую производительность благодаря реализации на C.

xml.dom.minidom

• Встроена по умолчанию.
• Может парсить из строки и файлов.
• Способна создавать и редактировать XML-строки и файлы.
• Предоставляет DOM-интерфейс для работы с XML.

xml.sax

• Встроена по умолчанию.
• Может парсить из строки и файлов.
• Позволяет создавать собственные обработчики для XML-элементов.
• Эффективна для обработки больших XML-файлов, так как не загружает весь документ в память.

xmlschema

• Может парсить из строки и файлов.
• Выполняет валидацию XML-документов.
• Способна генерировать объекты из XML-данных.
• Позволяет создавать XML-схемы.

xmltodict

• Может парсить из строки и файлов.
• Преобразует XML в словари.
• Способна создавать XML-строки из словарей.

BeautifulSoup

• Может парсить XML и HTML из строки и файлов.

Парсинг данных из JSON и XML

Парсинг — это извлечение данных для последующей обработки и анализа. Давайте представим, что мы ищем новую работу. Для этого ходим по сайтам IT-агентств и сохраняем их контакты себе в таблицу. Это простейший пример парсинга.

Примеры извлечения JSON данных в разных библиотеках

Предположим, что нам надо спарсить вот этот код и вытащить из него значение "occupation".

json

Если данные уже находятся у нас в виде строки, то мы можем вызвать функцию json.loads() для извлечения:

Здесь мы принимаем JSON и записываем его в словарь Python. Далее выводим значение ключа "occupation".

simplejson

Представим, что у нас не строка, а файл json_string.json:

Мы открываем файл json_string.json и называем его f. Далее читаем JSON из файла f с помощью json.load(f) и превращаем в словарь data. В конце возвращаем значение, ключа "occupation".

ujson

Здесь происходит то же, что и в примере выше: ujson.load(f) читает JSON из файла f и преобразует его в словарь Python, который сохраняется в data.

orjson

Если мы хотим спарсить данные по url, то понадобиться библиотека requests:

Функция orjson.loads(response.content) парсит по url JSON, и преобразует их в словарь data, после чего мы можем обращаться к значениям этого словаря.

Примеры извлечения XML данных в разных библиотеках

Представим, что нам нужно спарсить значение из тега name в этом коде:

xml.etree.ElementTree

При помощи ET.fromstring(xml_string) мы извлекаем XML из строки и создаем объект root — он представляет корневой элемент. Далее при помощи индекса root[0] обращаемся к первому дочернему элементу <name> и выводим его значение.

lxml

etree.fromstring(xml_string) извлекает данные из xml_string в объект root. Как и в примере выше, мы можем обращаться к элементам и атрибутам через root и его дочерние элементы при помощи индекса, например, root[0].

xml.dom.minidom

Здесь minidom.parseString(xml_string) извлекает XML из строки и создает объект dom. Далее команда находит первый элемент с тегом <name>, записывает его в переменную name_element и выводит значение.

xmltodict

Библиотека анализирует XML структуру и создает словарь, где ключи — это теги XML, а значения — дочерние элементы. Мы обращаемся к элементу <name> и выводим его.

BeautifulSoup

При помощи BeautifulSoup(xml_string, 'xml') мы парсим из строки xml_string и указываем, что нам нужен формат xml. Далее сохраняем данные в объект soup, находим элемент с тегом <name> и выводим его значение.

Генерация данных JSON и XML в Python

Примеры генерации JSON в разных библиотеках

Библиотеки python используют схожий подход для генерации JSON. Делается это при помощи функции dumps(). Вот несколько примеров:

json

SimpleJSON

ujson

orjson

Мы создали словарь data с данными и преобразовали их в JSON.

dumps() конвертирует объект в JSON. Но если необходимо записать данные в файл, то стоит воспользоваться функцией dump().

Примеры генерации XML в разных библиотеках

Если мы хотим записать XML файл, то нам понадобятся следующие функции:

• ET.Element() — создает корневой элемент
• ET.SubElement() — создает дочерние элементы
• ET.ElementTree() — сохраняет дерево из элементов
• tree.write() — записывает xml данные в файл

xml.etree.ElementTree

В этом примере мы создаем корневой элемент person, добавляем дочерние элементы name и age, прописываем их значения, а затем сохраняем XML дерево в файл person.xml.

lxml

Здесь мы тоже создаем корневой элемент, добавляем дочерние элементы, формируем дерево и записываем в файл.

xmltodict

А это пример создания XML из словаря. Библиотека анализирует структуру словаря и создает XML документ. Ключи словаря становятся тегами, а значения — текстовым содержимым или вложенными элементами.

Примеры валидации данных в JSON и XML

Валидация — это проверка кода на соответствие определенным правилам. Например, мы создаем форму для регистрации, где будет пароль только из латинских знаков. Следовательно, нам нужно проверять символы, которые будут вводить пользователи при регистрации.

Примеры валидации JSON в jsonschema и Cerberus

jsonschema

Мы прописываем схему "schema", которая определяет наши правила. Данные должны быть объектом с ключами "name" и "age". Ключ "name" принимает только строки в качестве значений, а "age" только числа".

Далее мы определяем два набора данных. Один валидный, другой нет.

Проверяем, соответствуют ли valid_data и invalid_data заданной схеме. Выводим сообщение о валидности/невалидности данных.

Cerberus

Задаем схему с правилами. Указываем, что у нас обязательно должен быть ключ "name", который принимает строку. Его наличие обязательно благодаря команде "required": True. Ключ "age" принимает только числа.

Здесь мы передаем нашу схему в объект validator и определяем два набора данных. Первый — валидный, второй с ошибкой. В нем отсутствует "name".

Проверяем корректность кода и выводим сообщения.

Примеры валидации XML в lxml и xmlschema

lxml

Это XML-данные, которые мы будем проверять на ошибки.

А это наша схема с правилами. Давайте разберем ее более детально.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> — означает, что этот код является схемой и ссылается на определенный стандарт.

<xs:element name="person"> — здесь мы говорим, что элемент с тегом <person> должен быть корневым в проверяемом XML коде.

<xs:complexType> и <xs:sequence> означают, что у нас несколько элементов и они должны идти в определенном порядке. Далее мы указываем наши элементы и их тип.

xml_data и xsd_date являются строками. Чтобы выполнить валидацию, их необходимо преобразовать в объект python. Делаем это при помощи метода etree.fromstring(). Теперь у нас есть объекты xml_doc и xsd_doc. В них хранится информация о нашем xml коде и схеме.

При помощи xsd_doc создаем новый объект схемы.

Валидируем xml_doc и выводим сообщение о результате.

xmlschema

Рассмотрим вариант, при котором наша схема расположена в отдельном файле.

Импортируем библиотеку и указываем файл с правилами.

Определяем два набора данных для проверки. Один валидный, другой нет.

Проверяем валидность данных в функции validate() и выводим сообщения о результате валидации при помощи условной конструкции try: except.

Работа с API JSON и XML

Теперь рассмотрим несколько простых примеров передачи данных по API.

Получение данных из API с использованием JSON

Импортируем библиотеку для работы с API requests и записываем адрес в переменную url.

Отправляем запрос на наш API и проверяем ответ. Если он успешный, то записываем его в словарь data.

Выводим значения элементов name и email. Если их нет, то код покажет ошибку.

Отправка данных в API с использованием JSON

Импортируем requests, записываем адрес API в url и определяем данные, которые надо отправить.

Отправляем POST-запрос с данными на сервер.

Если всё работает, то получаем статус-код 201 и выводим сообщение об успехе. Если данные не отправились, то выводим сообщение с ошибкой.

Получение данных из API с использованием XML

Импортируем библиотеки, записываем API-адрес в переменную url и отправляем GET-запрос.

Если запрос отправлен успешно, обращаемся к элементу name и выводим его значение.

Отправка данных в API с использованием XML

Всё по классике. Импортируем requests и xmltodict. Записываем API в переменную url. Создаем словарь с данными для отправки.

Создаем словарь headers , в который записываем заголовок нашего запроса. Отправляем его.

Проверяем код ответа. Если все отправилось, то выводим соответствующее сообщение. Если нет — выводим ошибку.

Конвертация JSON и XML

Пример конвертации JSON в XML

Импортируем библиотеку и прописываем JSON, который будем конвертировать.

Конвертируем JSON в XML, сохраняем данные в xml_data и выводим результат.

Пример конвертации XML в JSON

Импортируем библиотеки и определяем XML-данные.

Преобразуем данные в словарь json_data.

Конвертируем словарь в JSON и выводим его.

Оптимизация работы с JSON и XML

Встроенные библиотеки Python, такие как json и xml.etree.ElementTree, обычно являются хорошим выбором для простых задач. Однако, для больших объемов или высокопроизводительных приложений они не подходят.

Производительность

С точки зрения производительности следует рассмотреть библиотеки: orjson и lxml.

Для JSON

orjson: Быстрая библиотека, написанная на Rust. Но поддерживает версию python от 3.6.

Эта диаграмма показывает скорость кодирования JSON данных в объект python на примере работы с API. Как видно, orjson справляется с задачей быстрее всех.

А здесь мы видим обратный процесс — преобразование Python в JSON-данные.

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

Для XML

lxml: основана на C-библиотеках libxml2 и libxslt, обычно быстрее, чем xml.etree.ElementTree, особенно для больших XML-документов и сложных операций.

На этом скриншоте изображены итоги теста Python-библиотек. Они анализировали XML-файл весом в 95 мегабайт, и lxml показала себя здесь лучшим образом.

Работа с памятью

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

Для JSON:

• ijson: Эта библиотека позволяет итеративно обрабатывать данные, не загружая весь документ.

Для XML:

• xml.sax: обрабатывает данные по частям, не загружая всё в память.
• lxml: также обрабатывает большие объемы информации по кусочкам.

Если вы пользуетесь другими библиотеками или фичами — рассказывайте о них в комментариях.

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

Безопасность данных

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

Целостность и корректность данных

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

Проектирование API

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

Асимметрия между XML и бинарной сериализацией

Сериализация объектов — это процесс преобразования объектов в формат, который можно сохранить или передать, и существует множество методов для этого, включая XML и бинарную сериализацию. Эти два метода обладают определёнными различиями, которые можно объяснить их назначением и особенностями.

Разные цели

XML и бинарная сериализация были разработаны для решения разных задач. Бинарная сериализация предназначена для сохранения сложных графов объектов .NET с полной информацией о них. Она сохраняет все детали состояния объекта, включая приватные члены и типы данных. XML-сериализация, с другой стороны, используется для поддержки протокола SOAP и обмена данными в формате, который легко читаем и понятен человеку. Она ориентирована на сохранение данных в открытом формате, который может быть прочитан и проверен без необходимости специализированных инструментов.

Приватные члены и безопасность

Как уже упоминалось, XML-сериализация игнорирует приватные члены для обеспечения безопасности и целостности данных. Бинарная сериализация, напротив, сохраняет все данные объекта, включая приватные члены. Поэтому для бинарной сериализации требуется дополнительная настройка, чтобы контролировать, какие данные сохраняются, и для этого используются атрибуты, такие как `[NonSerialized]`, для исключения определённых полей из сериализации.

Пример класса с приватными членами:

Циклические ссылки

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

Пример класса с циклической ссылкой:

Указание типа данных

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

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