[{"data":1,"prerenderedAt":663},["ShallowReactive",2],{"course:aidt-bac-webdev":3,"course:aidt-bac-webdev:topics":65,"course:aidt-bac-webdev:project":51},{"id":4,"title":5,"body":6,"course_slug":50,"description":46,"env_label":51,"env_url":51,"extension":52,"group":53,"is_course_project":54,"is_index":55,"level":56,"meta":57,"navigation":55,"path":61,"section":51,"seo":62,"stem":63,"topic_number":51,"topic_slug":51,"__hash__":64},"courses\u002Fcourses\u002Faidt-bac-webdev\u002Findex.md","Разработка Web-приложений",{"type":7,"value":8,"toc":45},"minimark",[9,13,18],[10,11,5],"h1",{"id":12},"разработка-web-приложений",[14,15,17],"h2",{"id":16},"документы","Документы",[19,20,21,31,38],"ul",{},[22,23,24,25,30],"li",{},"Требования к содержанию и оформлению — ",[26,27,29],"a",{"href":28},".\u002Fshared\u002FSTYLEGUIDE","shared\u002FSTYLEGUIDE.md",".",[22,32,33,34,30],{},"Содержание курса — ",[26,35,37],{"href":36},".\u002Ftopics","topics.md",[22,39,40,41,30],{},"Отклонения от общих правил и рамки курса — ",[26,42,44],{"href":43},".\u002F.claude\u002FCLAUDE",".claude\u002FCLAUDE.md",{"title":46,"searchDepth":47,"depth":47,"links":48},"",2,[49],{"id":16,"depth":47,"text":17},"aidt-bac-webdev",null,"md","bachelor",false,true,"бакалавриат",{"topics_count":58,"has_lr":55,"has_pz":54,"has_course_project":55,"final_assessment":59,"tech_focus":60},9,"экзамен","HTML, CSS, JavaScript, Fetch, REST API (json-server)","\u002Fcourses\u002Faidt-bac-webdev",{"title":5,"description":46},"courses\u002Faidt-bac-webdev\u002Findex","Eg-Fy-Q5txiKorp__R7r9qvHTH9-4sLZty-4p0NRxVM",[66],{"id":67,"title":68,"body":69,"course_slug":50,"description":77,"env_label":51,"env_url":51,"extension":52,"group":51,"is_course_project":54,"is_index":54,"level":51,"meta":655,"navigation":55,"path":656,"section":657,"seo":658,"stem":659,"topic_number":660,"topic_slug":661,"__hash__":662},"courses\u002Fcourses\u002Faidt-bac-webdev\u002Ftopic-01-content.md","Веб, HTTP и устройство веб-приложения",{"type":7,"value":70,"toc":632},[71,74,78,82,87,103,106,110,123,126,129,133,137,150,160,205,218,229,252,256,269,316,325,436,445,450,454,463,472,478,482,486,498,501,510,513,516,520,527,530,534,547,550,554,558,561,564,573,576,580,583,586,590,593,596,599,603],[10,72,68],{"id":73},"веб-http-и-устройство-веб-приложения",[75,76,77],"p",{},"Курс посвящён веб-приложениям: программам, которые пользователь открывает в браузере, а данные которых живут на сервере. Прежде чем написать первую строку разметки, разберём механику, на которой держится всё остальное: что происходит между вводом адреса и появлением страницы на экране. Адрес, запрос, ответ, разбор документа, запросы за ресурсами, отрисовка — эта цепочка повторяется при каждом открытии любой страницы, и каждое её звено в дальнейшем получит отдельную тему. Здесь мы пройдём цепочку целиком, чтобы дальше было видно, какое место занимает HTML, где вступает в дело CSS и зачем странице скрипт.",[14,79,81],{"id":80},"гипертекст-и-всемирная-паутина","Гипертекст и Всемирная паутина",[83,84,86],"h3",{"id":85},"гипертекст-и-гипермедиа","Гипертекст и гипермедиа",[75,88,89,90,102],{},"Гипертекст — текст, содержащий ссылки на другие тексты, по которым читатель переходит в выбранном им порядке. Обычная книга читается от начала к концу; гипертекст не имеет единственного порядка чтения, его задаёт сам читатель, выбирая ссылку за ссылкой. Термин предложил Тед Нельсон в 1965 году, описывая файловую структуру для документов, которые меняются и связаны друг с другом ",[91,92,95],"sup",{"className":93},[94],"cite",[26,96,98],{"href":97},"#ref-1",[99,100,101],"span",{},"1",". Он же ввёл слово «гипермедиа» — то же самое, но для изображений, звука и видео; в обиходе закрепился первый термин, хотя современный веб гипермедийный по существу.",[75,104,105],{},"Ссылка — основная операция гипертекста, и на ней держится вся дальнейшая конструкция. Если связанные документы лежат на одной машине, ссылке достаточно имени файла. Если на разных, потребуются две вещи: способ назвать документ так, чтобы имя было понятно на любой машине сети, и способ доставить документ по этому имени. Первая задача решается адресом, вторая — протоколом передачи.",[83,107,109],{"id":108},"от-идеи-до-современного-состояния","От идеи до современного состояния",[75,111,112,113,122],{},"В 1989 году Тим Бернерс-Ли, работавший в Европейской организации по ядерным исследованиям (CERN), предложил систему для хранения служебной документации, в которой документы были бы связаны ссылками и доступны с любого компьютера сети ",[91,114,116],{"className":115},[94],[26,117,119],{"href":118},"#ref-2",[99,120,121],{},"2",". Из этого предложения выросли три составляющие, определяющие веб до сих пор: единообразный адрес ресурса (URL), протокол передачи гипертекста (HTTP) и язык разметки гипертекста (HTML). К концу 1990 года были написаны первый сервер и первый браузер, а в 1991 году система стала доступна за пределами CERN.",[75,124,125],{},"Веб часто отождествляют с интернетом, и это неточно. Интернет — сеть сетей, обеспечивающая доставку пакетов между машинами; он существовал за двадцать лет до веба и обслуживает электронную почту, передачу файлов и многое другое. Веб — один из сервисов поверх интернета: набор соглашений о том, как называть документы, как их запрашивать и как записывать. Именно эти соглашения мы будем изучать.",[75,127,128],{},"Базовая механика веба за тридцать лет не изменилась: пользователь называет адрес, браузер отправляет запрос, сервер возвращает документ, браузер его отображает. Изменилось содержание документа. Первые страницы были статичными: сервер отдавал файл как есть. С появлением форм страница научилась отправлять данные обратно, и сервер стал собирать документы на лету. С появлением скриптов страница научилась меняться прямо в браузере и запрашивать данные, не перезагружаясь. Так документ превратился в приложение: программу, которая выполняется в браузере и разговаривает с сервером. Механика запроса и ответа осталась прежней, и потому начинать надо с неё.",[14,130,132],{"id":131},"адресация-и-протокол","Адресация и протокол",[83,134,136],{"id":135},"url","URL",[75,138,139,140,149],{},"Единообразный указатель ресурса (Uniform Resource Locator, URL) — строка, по которой браузер находит ресурс в сети. Правила её записи закреплены стандартом ",[91,141,143],{"className":142},[94],[26,144,146],{"href":145},"#ref-3",[99,147,148],{},"3",". Рассмотрим адрес, в котором присутствуют все составляющие:",[151,152,157],"pre",{"className":153,"code":155,"language":156},[154],"language-text","https:\u002F\u002Ftasks.example.ru:8080\u002Fapi\u002Ftasks?status=active&page=2#top\n","text",[158,159,155],"code",{"__ignoreMap":46},[75,161,162,163,166,167,170,171,174,175,178,179,182,183,178,186,188,189,192,193,196,197,200,201,204],{},"Схема ",[158,164,165],{},"https"," называет протокол, по которому следует обращаться к ресурсу. Хост ",[158,168,169],{},"tasks.example.ru"," — имя машины в сети; перед отправкой запроса браузер переводит его в числовой адрес, обращаясь к системе доменных имён (DNS). Порт ",[158,172,173],{},"8080"," — номер, по которому операционная система сервера различает программы, принимающие соединения; если порт не указан, он подразумевается схемой: ",[158,176,177],{},"80"," для ",[158,180,181],{},"http",", ",[158,184,185],{},"443",[158,187,165],{},". Путь ",[158,190,191],{},"\u002Fapi\u002Ftasks"," указывает ресурс внутри хоста; исторически он совпадал с путём к файлу на диске, у приложения же путь — имя, которое сервер истолковывает сам. Параметры запроса после ",[158,194,195],{},"?"," — пары «имя — значение», соединённые знаком ",[158,198,199],{},"&","; так странице передают уточнения: фильтр, номер страницы, поисковую строку. Фрагмент после ",[158,202,203],{},"#"," адресует часть документа и на сервер не отправляется: с ним работает только браузер, прокручивая страницу к нужному месту.",[206,207,208,209,208,214],"figure",{},"\n  ",[210,211],"img",{"src":212,"alt":213},"\u002Fimg\u002Faidt-bac-webdev\u002Ftopic-01\u002Furl_anatomy.svg","Составляющие URL: схема, хост, порт, путь, параметры запроса, фрагмент",[215,216,217],"figcaption",{},"Составляющие адреса: схема, хост, порт, путь, параметры запроса и фрагмент",[75,219,220,221,224,225,228],{},"В адресе допустимы латинские буквы, цифры и небольшой набор знаков. Всё остальное — кириллица, пробел, сами служебные знаки внутри значений — передаётся в закодированном виде: каждый байт представления UTF-8 записывается как знак ",[158,222,223],{},"%"," и два шестнадцатеричных разряда. Слово «задачи» превращается в ",[158,226,227],{},"%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%B8",", по два байта на букву. Адресная строка браузера показывает адрес в раскодированном виде для удобства чтения, но на сервер уходит закодированный.",[75,230,231,232,235,236,239,240,243,244,247,248,251],{},"Адрес может быть относительным: ссылка ",[158,233,234],{},"tasks.html"," в документе ",[158,237,238],{},"https:\u002F\u002Fexample.ru\u002Fapp\u002Findex.html"," разрешается в ",[158,241,242],{},"https:\u002F\u002Fexample.ru\u002Fapp\u002Ftasks.html",", а ",[158,245,246],{},"\u002Ftasks.html"," — в ",[158,249,250],{},"https:\u002F\u002Fexample.ru\u002Ftasks.html",", от корня хоста. Разметка документа почти целиком состоит из относительных адресов, и правила их разрешения понадобятся уже в теме 2.",[83,253,255],{"id":254},"http-запрос-и-ответ","HTTP: запрос и ответ",[75,257,258,259,268],{},"Протокол передачи гипертекста (HyperText Transfer Protocol, HTTP) устроен по схеме «запрос — ответ»: клиент отправляет запрос, сервер возвращает ответ, после чего обмен завершён. Актуальное описание семантики протокола содержится в стандарте ",[91,260,262],{"className":261},[94],[26,263,265],{"href":264},"#ref-4",[99,266,267],{},"4",". Сообщения обоих направлений имеют одинаковое строение: стартовая строка, заголовки, пустая строка, тело.",[75,270,271,272,275,276,279,280,283,284,287,288,291,292,295,296,299,300,303,304,307,308,311,312,315],{},"Стартовая строка запроса содержит метод, адрес ресурса и версию протокола: ",[158,273,274],{},"GET \u002Fapi\u002Ftasks?status=active HTTP\u002F1.1",". Метод называет действие. ",[158,277,278],{},"GET"," запрашивает ресурс и не имеет тела; такой запрос не должен ничего менять на сервере, поэтому его можно повторять и кешировать. ",[158,281,282],{},"POST"," передаёт данные в теле запроса: отправка формы, создание записи. ",[158,285,286],{},"PUT"," заменяет ресурс целиком, ",[158,289,290],{},"PATCH"," изменяет его часть, ",[158,293,294],{},"DELETE"," удаляет. Заголовки запроса уточняют, кто и что просит: ",[158,297,298],{},"Host"," называет хост из адреса, ",[158,301,302],{},"User-Agent"," — программу-клиент, ",[158,305,306],{},"Accept"," и ",[158,309,310],{},"Accept-Language"," — предпочтительные формат и язык ответа, ",[158,313,314],{},"Cookie"," возвращает серверу ранее выданные им данные.",[206,317,208,318,208,322],{},[210,319],{"src":320,"alt":321},"\u002Fimg\u002Faidt-bac-webdev\u002Ftopic-01\u002Fhttp_exchange.svg","Строение HTTP-запроса и ответа: стартовая строка, заголовки, пустая строка, тело",[215,323,324],{},"Запрос клиента и ответ сервера имеют одинаковое строение: стартовая строка, заголовки, пустая строка и тело",[75,326,327,328,331,332,335,336,339,340,343,344,347,348,351,352,307,355,358,359,362,363,366,367,370,371,374,375,307,378,381,382,385,386,389,390,393,394,307,397,400,401,403,404,406,407,410,411,182,414,182,417,182,420,423,424,427,428,431,432,435],{},"Стартовая строка ответа содержит версию протокола, код состояния и его словесное пояснение: ",[158,329,330],{},"HTTP\u002F1.1 200 OK",". Код — трёхзначное число, первая цифра которого задаёт класс. Класс ",[158,333,334],{},"2xx"," означает успех: ",[158,337,338],{},"200"," — ресурс в теле ответа, ",[158,341,342],{},"201"," — ресурс создан, ",[158,345,346],{},"204"," — выполнено, тела нет. Класс ",[158,349,350],{},"3xx"," — перенаправление: ",[158,353,354],{},"301",[158,356,357],{},"302"," сообщают, что ресурс находится по адресу из заголовка ",[158,360,361],{},"Location",", и браузер переходит по нему сам; ",[158,364,365],{},"304"," означает, что ресурс не изменился и браузер может взять копию из своего кеша. Класс ",[158,368,369],{},"4xx"," — ошибка на стороне клиента: ",[158,372,373],{},"400"," — запрос составлен неверно, ",[158,376,377],{},"401",[158,379,380],{},"403"," — требуется вход или доступ запрещён, ",[158,383,384],{},"404"," — по такому адресу ничего нет. Класс ",[158,387,388],{},"5xx"," — ошибка на стороне сервера: ",[158,391,392],{},"500"," — сбой программы, ",[158,395,396],{},"502",[158,398,399],{},"503"," — сервер недоступен. Важная особенность: код ",[158,402,384],{}," или ",[158,405,392],{}," — это полноценный ответ с заголовками и, как правило, с телом; с точки зрения протокола обмен состоялся, просто результат отрицательный. Заголовки ответа описывают тело: ",[158,408,409],{},"Content-Type"," называет формат (",[158,412,413],{},"text\u002Fhtml",[158,415,416],{},"text\u002Fcss",[158,418,419],{},"application\u002Fjson",[158,421,422],{},"image\u002Fsvg+xml","), ",[158,425,426],{},"Content-Length"," — размер, ",[158,429,430],{},"Cache-Control"," — как долго ответ можно хранить в кеше; ",[158,433,434],{},"Set-Cookie"," передаёт клиенту данные, которые тот будет возвращать в последующих запросах.",[75,437,438,439,441,442,444],{},"Последний заголовок отвечает на вопрос, который протокол иначе оставляет открытым. HTTP не хранит состояния: сервер не помнит предыдущих запросов клиента, и каждый запрос для него самостоятелен. Чтобы сервер узнавал вернувшегося пользователя, состояние переносится в самом обмене: сервер выдаёт клиенту метку в ",[158,440,434],{},", клиент прикладывает её к каждому следующему запросу в ",[158,443,314],{},". На этом устроены сеансы и вход в систему, к чему мы вернёмся в теме 9.",[75,446,162,447,449],{},[158,448,165],{}," означает тот же HTTP, но поверх шифрованного соединения (TLS). Шифрование скрывает содержимое обмена от посредников, а сертификат сервера подтверждает, что клиент разговаривает именно с тем хостом, который назван в адресе. Строение сообщений при этом не меняется. Не меняется оно и в новых версиях протокола: HTTP\u002F2 и HTTP\u002F3 передают те же методы, коды и заголовки в двоичном виде и эффективнее используют соединение, но для автора приложения выглядят так же, как текстовый HTTP\u002F1.1.",[83,451,453],{"id":452},"цикл-загрузки-страницы","Цикл загрузки страницы",[75,455,456,457,459,460,462],{},"Соединим адрес и протокол в последовательность действий, которую браузер выполняет при открытии страницы. Получив адрес, браузер узнаёт у системы доменных имён числовой адрес хоста, устанавливает с ним соединение — для ",[158,458,165],{}," ещё и согласует шифрование — и отправляет запрос ",[158,461,278],{}," с путём из адреса. Сервер отвечает документом. Браузер начинает разбирать документ, не дожидаясь его конца, и по мере разбора обнаруживает ссылки на ресурсы: таблицы стилей, скрипты, изображения, шрифты. За каждым ресурсом отправляется отдельный запрос, нередко к другим хостам: библиотеки и шрифты часто лежат в сетях доставки содержимого, счётчики посещений — на серверах аналитики. Получив стили, браузер вычисляет раскладку и отрисовывает страницу; получив скрипты, выполняет их, и скрипты, в свою очередь, могут отправить новые запросы уже за данными.",[206,464,208,465,208,469],{},[210,466],{"src":467,"alt":468},"\u002Fimg\u002Faidt-bac-webdev\u002Ftopic-01\u002Fpage_load_sequence.svg","Последовательность запросов при загрузке страницы: документ, затем ресурсы, позже данные по действию пользователя",[215,470,471],{},"Загрузка одной страницы: запрос документа, затем запросы за ресурсами, указанными в нём, позже запросы за данными без перезагрузки",[75,473,474,475,477],{},"Из этой последовательности следуют два наблюдения. Первое: одна страница — это десятки запросов, и перечень их определяет документ: браузер запрашивает ровно то, на что документ ссылается. Второе: повторное открытие той же страницы обходится дешевле. Ресурсы, для которых сервер разрешил кеширование, браузер берёт из локальной копии, не обращаясь к сети, либо спрашивает сервер, изменились ли они, и получает короткий ответ ",[158,476,365],{}," вместо тела. Так протокол без состояния обеспечивает быстрый повторный доступ, не храня ничего о клиенте.",[14,479,481],{"id":480},"браузер-как-среда-выполнения","Браузер как среда выполнения",[83,483,485],{"id":484},"архитектура-браузера","Архитектура браузера",[75,487,488,489,30],{},"Браузер — программа, которая получает документы по HTTP и превращает их в изображение на экране и в среду для выполнения скриптов. Внутри он состоит из нескольких подсистем, и их разделение объясняет многое из того, что встретится в курсе ",[91,490,492],{"className":491},[94],[26,493,495],{"href":494},"#ref-5",[99,496,497],{},"5",[75,499,500],{},"Сетевой слой выполняет запросы и принимает ответы: именно он реализует протокол, разобранный выше. Разборщик HTML превращает текст документа в дерево элементов — объектную модель документа (DOM), с которой затем работают остальные подсистемы и скрипты. Разборщик CSS строит из таблиц стилей набор правил и сопоставляет их элементам дерева. Движок отрисовки вычисляет по дереву и стилям положение и размер каждого элемента (раскладку) и рисует результат. Интерпретатор JavaScript выполняет скрипты, которые читают и изменяют дерево документа, отчего движок перерисовывает страницу. Хранилище держит cookies и данные, которые страница сохраняет между посещениями.",[206,502,208,503,208,507],{},[210,504],{"src":505,"alt":506},"\u002Fimg\u002Faidt-bac-webdev\u002Ftopic-01\u002Fbrowser_architecture.svg","Подсистемы браузера: сетевой слой, разбор HTML и CSS, раскладка и отрисовка, интерпретатор JavaScript, хранилище",[215,508,509],{},"Подсистемы браузера: сетевой слой доставляет документ и ресурсы, разборщики строят дерево и стили, движок отрисовывает страницу, интерпретатор выполняет скрипты",[75,511,512],{},"Ключевые подсистемы объединяют в движок, и движков в современных браузерах три. Blink с интерпретатором V8 лежит в основе Chrome, а также Edge, Opera и Яндекс Браузера; WebKit с JavaScriptCore — в основе Safari; Gecko со SpiderMonkey — в основе Firefox. Для автора приложения это означает, что проверять страницу достаточно в трёх браузерах разных семейств, а не во всех существующих.",[75,514,515],{},"Каждая вкладка современного браузера выполняется в отдельном процессе, изолированном от других вкладок и от операционной системы. Страница не может читать файлы на диске пользователя, обращаться к другим вкладкам или к произвольным программам: всё, что ей доступно, — это набор интерфейсов, предоставленных браузером. Ограничение распространяется и на сеть: скрипт со страницы одного хоста по умолчанию не может читать ответы другого хоста. Это правило одного источника ещё встретится в теме 8, когда клиент и сервер данных окажутся на разных портах.",[83,517,519],{"id":518},"инструменты-разработчика","Инструменты разработчика",[75,521,522,523,526],{},"Все перечисленные подсистемы браузер показывает изнутри через инструменты разработчика, встроенные в каждый современный браузер и открываемые клавишей ",[158,524,525],{},"F12",". Панель Elements отображает дерево документа — то, что построил разборщик, а не исходный текст; дерево живое, его можно править на месте и видеть результат. Панель Console выполняет команды JavaScript в контексте страницы и показывает ошибки скриптов. Панель Network перечисляет все запросы страницы с методом, кодом ответа, типом и размером, а по щелчку раскрывает заголовки и тело; здесь протокол виден без посредников. Панель Application показывает хранилище: cookies и сохранённые страницей данные.",[75,528,529],{},"Инструменты разработчика — рабочий инструмент курса на всём его протяжении. Проверять разметку, отлаживать стили, исследовать поведение скриптов и наблюдать обмен с сервером мы будем в них, а не догадками.",[14,531,533],{"id":532},"стандартизация","Стандартизация",[75,535,536,537,546],{},"Соглашения, из которых состоит веб, закреплены в открытых стандартах, и знать, где они лежат, полезно с первого дня. Адрес и протокол описаны документами RFC, которые выпускает Инженерный совет интернета (IETF): URL — в RFC 3986, семантика HTTP — в RFC 9110. Язык HTML и объектная модель документа развиваются в группе WHATWG как «живой стандарт» без номеров версий: спецификация обновляется непрерывно, а привычное обозначение HTML5 осталось от последней нумерованной редакции ",[91,538,540],{"className":539},[94],[26,541,543],{"href":542},"#ref-6",[99,544,545],{},"6",". Консорциум W3C, основанный в 1994 году Бернерсом-Ли, с 2019 года отвечает за CSS, доступность (WCAG) и ряд программных интерфейсов. Язык JavaScript стандартизирован под именем ECMAScript организацией Ecma International, редакции выходят ежегодно.",[75,548,549],{},"Стандарты не гарантируют одинакового поведения: браузеры реализуют их с разной полнотой и в разное время. Поэтому рядом со спецификациями существуют таблицы совместимости, показывающие, какая возможность в каком браузере поддерживается, и справочники, пересказывающие стандарты человеческим языком, — среди них Mozilla Developer Network (MDN). В курсе мы будем опираться на спецификации и MDN как на источники, которым можно верить, и с осторожностью относиться к случайным руководствам, часть которых описывает веб десятилетней давности.",[14,551,553],{"id":552},"веб-приложение-и-его-части","Веб-приложение и его части",[83,555,557],{"id":556},"клиент-и-сервер","Клиент и сервер",[75,559,560],{},"Вернёмся к тому, с чего начали: веб-приложение — программа, разделённая на две части, работающие на разных машинах. Клиентская часть выполняется в браузере пользователя: она отображает данные, принимает ввод и выполняет ту часть логики, которую можно доверить браузеру. Серверная часть принимает запросы, применяет правила, хранит данные и отвечает документами или данными. Между ними — только HTTP: клиент ничего не знает об устройстве сервера, кроме адресов и формата ответов, сервер ничего не знает о клиенте, кроме содержания запросов.",[75,562,563],{},"Разделение обязанностей удобно рассмотреть на трёх поколениях веб-приложений. У статического сайта сервер — хранилище файлов: он отдаёт документы как есть, все данные записаны в самих документах, а любое изменение требует правки файлов. Приложение первого поколения отправляет ввод пользователя формой, сервер собирает новый документ на каждый запрос и возвращает его целиком; данные живут в базе на сервере, а каждое действие перезагружает страницу. Приложение с интерфейсом данных (API) разделяет обязанности иначе: сервер отдаёт данные в формате JSON, а страницу строит скрипт в браузере, запрашивая данные по мере надобности и меняя страницу без перезагрузки. Данные при этом по-прежнему хранятся на сервере, у клиента — только копия, которую он может дополнительно сохранить в браузере между посещениями.",[206,565,208,566,208,570],{},[210,567],{"src":568,"alt":569},"\u002Fimg\u002Faidt-bac-webdev\u002Ftopic-01\u002Fclient_server_roles.svg","Три поколения веб-приложений: статический сайт, страницы и формы, клиент и API — распределение обязанностей между сервером и клиентом",[215,571,572],{},"Три поколения веб-приложений: как распределены обязанности сервера и клиента, где хранятся данные и что происходит при действии пользователя",[75,574,575],{},"Из разделения следует правило, к которому курс будет возвращаться. Клиентская часть работает на машине пользователя и целиком ему подконтрольна: он может изменить скрипт, отправить запрос в обход страницы, подставить любые значения. Всё, что важно для целостности данных, проверяет сервер; клиент делает проверки ради удобства, а не ради защиты. В теме 9 эта граница между доверенной и недоверенной частью будет рассмотрена подробно.",[83,577,579],{"id":578},"ориентиры-курса","Ориентиры курса",[75,581,582],{},"Курс охватывает клиентскую часть веб-приложения. Мы будем писать документы на HTML, оформлять их на CSS, программировать поведение на JavaScript и обмениваться данными с сервером по HTTP. Серверную часть мы получим готовой: программа, отдающая данные в формате JSON по заранее известным адресам, будет запускаться одной командой, а её устройство рассмотрим обзорно в заключительной теме. Программирование серверной части, развёртывание и клиентские фреймворки остаются за рамками курса и лишь упоминаются там, где без этого не обойтись.",[75,584,585],{},"Учебное приложение курса — список задач. Оно пройдёт три состояния, повторяющие три поколения веб-приложений: сначала страница, размеченная и оформленная; затем приложение, работающее целиком в браузере и хранящее задачи локально; наконец, клиент, получающий и изменяющий задачи на сервере по HTTP. Инструменты на всём пути одни и те же: браузер с инструментами разработчика, текстовый редактор и локальный сервер, отдающий файлы по HTTP так же, как это делает настоящий.",[14,587,589],{"id":588},"итоги-темы","Итоги темы",[75,591,592],{},"Веб — сервис поверх интернета, построенный на трёх соглашениях: адресе ресурса, протоколе передачи и языке разметки. Адрес состоит из схемы, хоста, порта, пути, параметров запроса и фрагмента; всё, что выходит за пределы латиницы и цифр, кодируется побайтно. HTTP — протокол без состояния по схеме «запрос — ответ»; сообщения состоят из стартовой строки, заголовков и тела, метод называет действие, код состояния — результат, а ответ с кодом ошибки остаётся полноценным ответом.",[75,594,595],{},"Загрузка страницы — не один запрос, а последовательность: документ, затем ресурсы, на которые он ссылается, позже данные, запрошенные скриптом. Браузер разбирает документ в дерево, применяет стили, отрисовывает результат и выполняет скрипты в изолированном процессе; инструменты разработчика показывают каждую из этих подсистем.",[75,597,598],{},"Веб-приложение разделено на клиент в браузере и сервер, связанные только HTTP. Клиент отображает и принимает ввод, сервер хранит данные и проверяет всё, что важно. В курсе мы строим клиентскую часть: от документа на HTML до приложения, обменивающегося данными с готовым сервером.",[14,600,602],{"id":601},"литература","Литература",[604,605,608,612,616,620,624,628],"ol",{"className":606},[607],"references",[22,609,611],{"id":610},"ref-1","Nelson T. H. Complex Information Processing: A File Structure for the Complex, the Changing and the Indeterminate. — Proceedings of the 1965 20th National Conference, 1965, С. 84–100, DOI: 10.1145\u002F800197.806036.",[22,613,615],{"id":614},"ref-2","Berners-Lee T. Information Management: A Proposal. — 1989, https:\u002F\u002Fwww.w3.org\u002FHistory\u002F1989\u002Fproposal.html.",[22,617,619],{"id":618},"ref-3","Berners-Lee T., Fielding R. T., Masinter L. Uniform Resource Identifier (URI): Generic Syntax. — 2005, DOI: 10.17487\u002FRFC3986.",[22,621,623],{"id":622},"ref-4","Fielding R. T., Nottingham M., Reschke J. HTTP Semantics. — 2022, DOI: 10.17487\u002FRFC9110.",[22,625,627],{"id":626},"ref-5","Kosaka M. Inside look at modern web browser. — 2018, https:\u002F\u002Fdeveloper.chrome.com\u002Fblog\u002Finside-browser-part1.",[22,629,631],{"id":630},"ref-6","{WHATWG}. HTML Living Standard. — 2026, https:\u002F\u002Fhtml.spec.whatwg.org\u002Fmultipage\u002F.",{"title":46,"searchDepth":47,"depth":47,"links":633},[634,639,644,648,649,653,654],{"id":80,"depth":47,"text":81,"children":635},[636,638],{"id":85,"depth":637,"text":86},3,{"id":108,"depth":637,"text":109},{"id":131,"depth":47,"text":132,"children":640},[641,642,643],{"id":135,"depth":637,"text":136},{"id":254,"depth":637,"text":255},{"id":452,"depth":637,"text":453},{"id":480,"depth":47,"text":481,"children":645},[646,647],{"id":484,"depth":637,"text":485},{"id":518,"depth":637,"text":519},{"id":532,"depth":47,"text":533},{"id":552,"depth":47,"text":553,"children":650},[651,652],{"id":556,"depth":637,"text":557},{"id":578,"depth":637,"text":579},{"id":588,"depth":47,"text":589},{"id":601,"depth":47,"text":602},{},"\u002Fcourses\u002Faidt-bac-webdev\u002Ftopic-01-content","content",{"title":68,"description":77},"courses\u002Faidt-bac-webdev\u002Ftopic-01-content",1,"topic-01","yWl-0wSEirT8jkh5zz6jFj8EerRu6NSrdN4uV5AM1ds",1789142469858]