Серверные скрипты введение


Содержание

Введение в JavaScript

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

Что такое JavaScript?

Изначально JavaScript был создан, чтобы «сделать веб-страницы живыми».

Программы на этом языке называются скриптами. Они могут встраиваться в HTML и выполняться автоматически при загрузке веб-страницы.

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

Это отличает JavaScript от другого языка – Java.

Когда JavaScript создавался, у него было другое имя – «LiveScript». Однако, язык Java был очень популярен в то время, и было решено, что позиционирование JavaScript как «младшего брата» Java будет полезно.

Со временем JavaScript стал полностью независимым языком со своей собственной спецификацией, называющейся ECMAScript, и сейчас не имеет никакого отношения к Java.

Сегодня JavaScript может выполняться не только в браузере, но и на сервере или на любом другом устройстве, которое имеет специальную программу, называющуюся «движком» JavaScript.

У браузера есть собственный движок, который иногда называют «виртуальная машина JavaScript».

Разные движки имеют разные «кодовые имена». Например:

  • V8 – в Chrome и Opera.
  • SpiderMonkey – в Firefox.
  • …Ещё есть «Trident» и «Chakra» для разных версий IE, «ChakraCore» для Microsoft Edge, «Nitro» и «SquirrelFish» для Safari и т.д.

Эти названия полезно знать, так как они часто используются в статьях для разработчиков. Мы тоже будем их использовать. Например, если «функциональность X поддерживается V8», тогда «Х», скорее всего, работает в Chrome и Opera.

Движки сложны. Но основы понять легко.

  1. Движок (встроенный, если это браузер) читает («парсит») текст скрипта.
  2. Затем он преобразует («компилирует») скрипт в машинный язык.
  3. После этого машинный код запускается и работает достаточно быстро.

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

Что может JavaScript в браузере?

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

Возможности JavaScript сильно зависят от окружения, в котором он работает. Например, Node.JS поддерживает функции чтения/записи произвольных файлов, выполнения сетевых запросов и т.д.

В браузере для JavaScript доступно всё, что связано с манипулированием веб-страницами, взаимодействием с пользователем и веб-сервером.

Например, в браузере JavaScript может:

  • Добавлять новый HTML-код на страницу, изменять существующее содержимое, модифицировать стили.
  • Реагировать на действия пользователя, щелчки мыши, перемещения указателя, нажатия клавиш.
  • Отправлять сетевые запросы на удалённые сервера, скачивать и загружать файлы (технологии AJAX и COMET).
  • Получать и устанавливать куки, задавать вопросы посетителю, показывать сообщения.
  • Запоминать данные на стороне клиента («local storage»).

Чего НЕ может JavaScript в браузере?

Возможности JavaScript в браузере ограничены ради безопасности пользователя. Цель заключается в предотвращении доступа недобросовестной веб-страницы к личной информации или нанесения ущерба данным пользователя.

Примеры таких ограничений включают в себя:

JavaScript на веб-странице не может читать/записывать произвольные файлы на жёстком диске, копировать их или запускать программы. Он не имеет прямого доступа к системным функциям ОС.

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

Существуют способы взаимодействия с камерой/микрофоном и другими устройствами, но они требуют явного разрешения пользователя. Таким образом, страница с поддержкой JavaScript не может незаметно включить веб-камеру, наблюдать за происходящим и отправлять информацию в ФСБ.

Различные окна/вкладки не знают друг о друге. Иногда одно окно, используя JavaScript, открывает другое окно. Но даже в этом случае JavaScript с одной страницы не имеет доступа к другой, если они пришли с разных сайтов (с другого домена, протокола или порта).

Это называется «Политика одинакового источника» (Same Origin Policy). Чтобы обойти это ограничение, обе страницы должны согласиться с этим и содержать JavaScript-код, который специальным образом обменивается данными.

Это ограничение необходимо, опять же, для безопасности пользователя. Страница http://anysite.com , которую открыл пользователь, не должна иметь доступ к другой вкладке браузера с URL http://gmail.com и воровать информацию оттуда.

JavaScript может легко взаимодействовать с сервером, с которого пришла текущая страница. Но его способность получать данные с других сайтов/доменов ограничена. Хотя это возможно в принципе, для чего требуется явное согласие (выраженное в заголовках HTTP) с удалённой стороной. Опять же, это ограничение безопасности.

Подобные ограничения не действуют, если JavaScript используется вне браузера, например — на сервере. Современные браузеры предоставляют плагины/расширения, с помощью которых можно запрашивать дополнительные разрешения.

Что делает JavaScript особенным?

Как минимум, три сильные стороны JavaScript:

  • Полная интеграция с HTML/CSS.
  • Простые вещи делаются просто.
  • Поддерживается всеми основными браузерами и включён по умолчанию.

JavaScript – это единственная браузерная технология, сочетающая в себе все эти три вещи.

Вот что делает JavaScript особенным. Вот почему это самый распространённый инструмент для создания интерфейсов в браузере.

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

Языки «над» JavaScript

Синтаксис JavaScript подходит не под все нужды. Разные люди хотят иметь разные возможности.

Это естественно, потому что проекты разные и требования к ним тоже разные.

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

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


Примеры таких языков:

  • CoffeeScript добавляет «синтаксический сахар» для JavaScript. Он вводит более короткий синтаксис, который позволяет писать чистый и лаконичный код. Обычно такое нравится Ruby-программистам.
  • TypeScript концентрируется на добавлении «строгой типизации» для упрощения разработки и поддержки больших и сложных систем. Разработан Microsoft.
  • Flow тоже добавляет типизацию, но иначе. Разработан Facebook.
  • Dart стоит особняком, потому что имеет собственный движок, работающий вне браузера (например, в мобильных приложениях). Первоначально был предложен Google, как замена JavaScript, но на данный момент необходима его транспиляция для запуска так же, как для вышеперечисленных языков.

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

Серверные скрипты для начинающих

HTML-файл может содержать текст, html-теги и скрипты (сценарии).

Скрипты в html-файле могут выполняться на сервере.

Серверные скрипты

Серверное скриптование называют программированием поведения сервера.

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

Что такое серверные скрипты?

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

Что могут сделать серверные скрипты?

  • Динамически изменить, добавить или изменить любую информацию на веб-страницу
  • Реагировать на запросы пользователей или отправку данных из форм HTML
  • Доступ к любым данным или базам данных и возвращение (передача) результата в браузер
  • Настройка веб-страницы в соответствии с предпочтениями пользователей
  • Обеспечение безопасности, так как код серверных скриптов не может быть просмотрен с помощью браузера

Внимание: Так как скрипты выполняются на сервере, вам не требуется браузер с поддержкой чтения ASP/PHP файлов (файлы серверных скриптов). В этом важное отличие серверных скриптов от клиентских, потому что оборудование пользователя может не поддерживать клиентские скрипты.

ASP и PHP

На нашем сайте есть учебники по серверным скриптам ASP и PHP.

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

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

СТАТИСТИКА

ССЫЛКИ

Вопросы и пожелания вы можете отправить на почту: superxxx83@mail.ru или tokamame@gmail.com

На сайте установлена система отлова ошибок. Выделите ошибку и нажмите Ctrl+Enter. Сделаем Рунет грамотнее вместе!

Как сгенерировать SQL скрипт создания объектов и данных в Microsoft SQL Server?

Привет! Сегодня мы поговорим о том, как можно сгенерировать SQL скрипты создания объектов базы данных Microsoft SQL Server, включая сами данные, стандартными средствами SQL Server Management Studio (SSMS).

Что такое SQL скрипт объекта базы данных?

SQL скрипт объекта базы данных – это SQL инструкция, с помощью которой создается этот объект, сохраненная в текстовом файле.

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

Такой SQL скрипт можно открыть любым текстовым редактором, скопировать текст SQL запроса и выполнить, например, в среде SQL Server Management Studio, таким образом, создав объект базы данных, не разрабатывая соответствующие SQL инструкции самостоятельно.

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

Что могут содержать SQL скрипты?

SQL скрипты объектов базы данных могут содержать:

  • Инструкции создания таблиц (CREATE);
  • Заполнение таблиц (инструкции INSERT);
  • Определение представлений, функций, хранимых процедур, триггеров;
  • Определение ограничений и индексов;
  • Определение создания других объектов;
  • И другие SQL инструкции.

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

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

Или для того, чтобы передать эти SQL скрипты другому администратору, разработчику или заказчику, чтобы он создал подобные объекты на своем экземпляре SQL Server.

Таким образом, такие SQL скрипты необходимы для хранения копий SQL инструкций, с помощью которых создавались объекты базы данных.

Как создать SQL скрипт объекта базы данных в Microsoft SQL Server?

Так как SQL скрипт – это обычный текстовый файл, его можно создать вручную, например, когда Вы разрабатываете объект БД, Вы просто сохраняете SQL инструкцию в файл, и добавляете в него по мере необходимости другие SQL инструкции.

Однако также возможно автоматически сгенерировать SQL скрипты объектов базы данных специальными инструментами, например, в среде SQL Server Management Studio (SSMS). А как это делается, я сейчас и покажу.

Заметка! Если Вы хотите изучить язык T-SQL, рекомендую почитать книгу «Путь программиста T-SQL».

Создание SQL скрипта объекта базы данных Microsoft SQL Server

В качестве исходных данных у меня будет база данных TestDB и таблица Goods, SQL скрипт которой мне и нужно создать. При этом мне необходимо, чтобы скрипт включал не только определение инструкции CREATE, но и данные, которые содержит эта таблица.

В качестве инструмента я буду использовать SQL Server Management Studio.


Итак, давайте начнем.

Шаг 1 – Запускаем SSMS

Сначала запускаем среду SQL Server Management Studio любым удобным для Вас способом, иными словами, никаких особых манипуляций с открытием SSMS выполнять не требуется.

Шаг 2 – Запускаем задачу «Сформировать скрипты»

Далее в обозревателе объектов находим нужную нам базу данных, затем открываем контекстное меню правой кнопкой мыши, ищем пункт «Задачи», и выбираем задачу «Сформировать скрипты».

В итоге запустится мастер создания скриптов. В окне «Введение» можем сразу нажать «Далее».

Шаг 3 – Выбираем объекты для включения в SQL скрипт

После этого нам нужно выбрать объекты базы данных, которые необходимо включить в SQL скрипт. При этом нам доступно два варианта:

  • Создать скрипт для всей базы данных и всех ее объектов – этот вариант предполагает, что Вам нужен скрипт создания всех объектов в БД;
  • Выбрать отдельные объекты базы данных – в данном случае в скрипт включатся SQL инструкции только тех объектов, которые Вы укажете.

Так как мне нужно сохранить только одну таблицу, я выбираю второй вариант и отмечаю нужную таблицу, т.е. в моем случае Goods.

Шаг 4 – Задание параметров SQL скрипта

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

Доступно 3 способа:

  • Сохранить в файл – при этом мы можем сами указать нужный нам каталог для сохранения;
  • Сохранить в буфер обмена;
  • Сохранить в новое окно запросов.

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

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

Также Вы можете включить в скрипты инструкции DROP на случай, если Вам нужно пересоздать объекты.

После того как все параметры заданы, нажимаем «ОК», а после для продолжения кнопку «Далее».

Шаг 5 – Проверка параметров и запуск процесса создания скрипта

На данном шаге все проверяем и запускаем сам процесс формирования скрипта, т.е. нажимаем «Далее».

Шаг 6 – Завершение процесса и результат

Когда процесс будет завершен, программа сообщит Вам об этом, нажимаем «Готово».

В результате в каталоге, который Вы указали в параметрах формирования скрипта, появится SQL скрипт, а по факту обычный текстовый файл с расширением .sql.

Если его открыть, например, текстовым редактором, то можно посмотреть на все SQL инструкции. Они будут выглядеть примерно следующим образом.

Видео-инструкция

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Серверный JavaScript — Руководство по Использованию — Пирамидин А.

Название: Серверный JavaScript — Руководство по Использованию.

Автор: Пирамидин А.

В этой книге рассматривается использование ядра и серверного JavaScript версии 1.4. JavaScript это созданный фирмой Netscape межплатформенный объектно-ориентированный язык скриптов (сценариев) для клиентских и серверных приложений.

Оглавление
Введение
Что Нового в Этой Версии?
Поддержка JavaScript 1.4
Изменения в Менеджере Приложений JavaScript
Что Вы Уже Должны Знать
Версии JavaScript
Где Найти Информацию о JavaScript
Обновление Предыдущей Версии
Обратная Совместимость с Предыдущими Версиями
Соглашения по Документам
Глава 1 JavaScript. Обзор.
Что Такое JavaScript?
Ядро, Клиентский и Серверный JavaScript
Ядро JavaScript
Клиентский JavaScript
Серверный JavaScript
JavaScript и Java
Отладка в JavaScript
Visual JavaScript
JavaScript и Спецификация ECMA
Соотношение Между Версиями JavaScript и ECMA
Документация JavaScript и Спецификация ECMA
JavaScript и Технология ECMA
ЧАСТЬ I. Разработка Серверных Приложений.
Глава 2 Введение
Архитектура Приложений JavaScript
Системные Требования
Информация о Конфигурации
Подключение Серверного JavaScript
Защита Менеджера Приложений
Настройка LiveConnect
Локализация Компилятора
Глава 3 Технология Разработки Приложений JavaScript
Основные Этапы Создания Приложения
Менеджер Приложений JavaScript
Создание Исходных Файлов Приложения
Компиляция Приложения
Инсталяция Нового Приложения
URL Приложения
Управление Доступом к Приложению
Модификация Приложения
Удаление Приложения
Старт, Остановка и Рестарт Приложения
Запуск Приложения
Отладка Приложения
Использование Менеджера Приложений для Отладки
Использование URL Отладки
Использование Функции debug
Публикация Приложения
Менеджер Приложений. Детали.
Конфигурация, Установки по Умолчанию.
За Кулисами
ЧАСТЬ II. Возможности Серверного JavaScript.
Глава 4 Быстрый Старт. Образец Приложения.
О Приложениях-Образцах Серверного JavaScript
Hello World
Что Делает Hello
Исходный Скрипт
Модифицирование Hello World
Hangman
Исходные Файлы
Отладка Hangman
Глава 5 Основы Серверного JavaScript
Что Делать и Где
Обзор Процессов Времени Выполнения
Серверный Язык. Обзор.
Прототипы
Использование
Окружение
Классы и Объекты
Внедрение JavaScript в HTML
Тэг SERVER
Обратные Кавычки
Когда Использовать Эту Технику?
Процессинг Времени Выполнения на Сервере
Конструирование HTML-Страницы
Генерация HTML
Очистка Буфера Вывода
Переход к Новому Клиентскому Запросу
Доступ к Переменным CGI
Сообщение Между Сервером и Клиентом
Отправка Сообщений с Клиента на Сервер
Отправка Значений с Сервера Клиенту
Использование «Куков»
Сбор Мусора
Обработка Ошибок в Серверном JavaScript
Глава 6 Обслуживание Сессий
Предопределённые Объекты. Обзор.
Объект request
Свойства
Работа с Картами Изображений
Объект client
Свойства
Уникальное Обращение к Объекту client
Создание Специального Объекта client
Объект project
Свойства
Совместное Использование Объекта project
Объект server
Свойства
Совместное Использование Объекта server
Техника Работы с Объектом client
Сравнение Разных Техник Обслуживания Клиента
Клиентская Техника
Серверная Техника
Период Существования Объекта client
Присоединение Свойств client’а к URL Вручную
Безопасное Использование Объектов с Блокировкой
Использование Lock-Экземпляров
Специальные Lock для Объектов project и server
Как Избежать Мёртвых Блокировок
Глава 7 Дополнительная Функциональность JavaScript
Почтовая Служба
Служба Файловой Системы
Проблемы Безопасности
Создание File-Объекта
Открытие и Закрытие Файла
Блокировка Файлов
Работа с Файлами
Пример
Работа с Внешними Библиотеками
Указания по Написанию Внешних Функций
Идентификация Файлов Библиотек
Регистрация Внешних Функций
Использование Внешних Функций в JavaScript
Манипуляции с Запросами и Ответами
Шапка Запроса
Тело Запроса
Шапка Ответа
ЧАСТЬ III. Служба LiveWire Database Service
Глава 8 Соединение с БД
Взаимодействие с Базами Данных
Соединение с БД
Пулы Соединений с БД
Однопоточные и Многопоточные БД
Рекомендации
Обслуживание Пулов Соединений
Совместное Использование Фиксированного Набора Пулов Соединений
Совместное Использование Массива Пулов Соединений
Индивидуальные Соединения с БД
Обслуживание Соединения по Нескольким Запросам
Ожидание Соединения
Запрашивание Свободного Соединения
Глава 9 Работа с БД
Взаимодействие с Реляционной БД
Автоматическое Отображение Результатов Выполнения Запроса
Выполнение Произвольных Операторов SQL
Манипуляции с Результатами Выполнения Запросов с Помощью Курсоров
Создание Курсора
Отображение Значений Записи
Отображение Выражений и Агрегатных Функций
Навигация с Помощью Курсоров
Работа со Столбцами
Изменение Информации Базы Данных
Обслуживание Транзакций
Методы Управления Транзакциями
Работа с Двоичными Данными
Вызов Хранимых Процедур
Обмен Информацией
Этапы Использования Хранимых Процедур
Регистрация Хранимой Процедуры
Определение Прототипа для Хранимой Процедуры
Выполнение Хранимой Процедуры
Работа с Наборами Результатов
Работа с Возвращаемыми Значениями
Работа с Параметрами Вывода
Исключения Informix и Sybase
Глава 10 Конфигурирование Базы Данных
О Службе LiveWire Database Service
Проверка Конфигурации Вашей БД
Поддерживаемые Клиенты БД и ODBC-Драйверы
DB2
Informix
Удалённый Informix
Локальный Informix
ODBC
ODBC DSN (Только NT)
OpenLink ODBC-Драйвер (Только Solaris)
Visigenic ODBC-Драйвер (Только Unix)
Oracle
Удалённый Oracle
Локальный Oracle
Sybase
Удалённый Sybase
Локальный Sybase
Sybase (Только Unix)
Глава 11 Конвертация Типов Данных
О Конвертации Типов Данных
Работа с Датами и БД
Конвертация Типа Данных Базой Данных
Глава 12. Обработка Ошибок LiveWire
Проверка Ошибочных Условий
Возвращаемые Значения
Число
Объект
Булево
Строка
Пустое
Методы для Работы с Ошибками
Статус-Коды
Глава 13 Приложения-Образцы Videoapp и Oldvideo
О Приложениях Videoapp и Oldvideo
Конфигурирование Окружения
Соединение с БД и Перекомпиляция
Создание БД
Запуск Videoapp
Исходные Файлы
Архитектура Приложения
Модифицирование Videoapp
ЧАСТЬ IV. Работа с LiveConnect
Глава 14. LiveConnect. Обзор.
Что Такое LiveConnect?
Работа с Оболочками
Взаимодействие JavaScript и Java
Объект Packages
Работа с Массивами Java
Обращение к Классу и Пакету
Аргументы Типа char
Пример Вызова Java из JavaScript
Взаимодействие Java и JavaScript
Использование Классов LiveConnect
Доступ к Серверному JavaScript
Конвертация Типов Данных
Конвертация из JavaScript в Java
Конвертация из Java в JavaScript
Словарь
Индекс.

Илон Маск рекомендует:  Как в Word обрезать рисунок

Что Такое LiveConnect?
LiveConnect даёт возможность подключать приложения серверного JavaScript к Java-компонентам и классам на сервере.

Вашему приложению JavaScript может понадобиться соединиться с кодом, написанным на других языках, таких как Java или C. Для подключения к Java-коду Вы используете функциональность LiveConnect. Для взаимодействия с кодом, написанным на других языках, у Вас есть несколько вариантов:

Вы можете обернуть/wrap Ваш код как Java-объект и использовать LiveConnect непосредственно.
Вы можете обернуть Ваш код как распределённый объект CORBA и использовать LiveConnect совместно с object request broker (ORB).
Вы можете напрямую включать внешние библиотеки в Ваше приложение.

Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Серверный JavaScript — Руководство по Использованию — Пирамидин А. — fileskachat.com, быстрое и бесплатное скачивание.

Скачать zip
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России. Купить эту книгу

Грамотная клиент-серверная архитектура: как правильно проектировать и разрабатывать web API

Рассказывает Владимир, веб-разработчик Noveo

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

Приближение первое: Действующие лица

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

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

Клиент и сервер

Сервером в данном случае мы считаем абстрактную машину в сети, способную получить HTTP-запрос, обработать его и вернуть корректный ответ. В контексте данной статьи совершенно не важны его физическая суть и внутренняя архитектура, будь то студенческий ноутбук или огромный кластер из промышленных серверов, разбросанных по всему миру. Нам в той же мере совершенно неважно, что у него под капотом, кто встречает запрос у дверей, Apache или Nginx, какой неведомый зверь, PHP, Python или Ruby выполняет его обработку и формирует ответ, какое хранилище данных используется: Postgresql, MySQL или MongoDB. Главное, чтобы сервер отвечал главному правилу — услышать, понять и простить ответить.

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

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

Философия REST

REST (Representational state transfer) изначально был задуман как простой и однозначный интерфейс для управления данными, предполагавший всего несколько базовых операций с непосредственным сетевым хранилищем (сервером): извлечение данных (GET), сохранение (POST), изменение (PUT/PATCH) и удаление (DELETE). Разумеется, этот перечень всегда сопровождался такими опциями, как обработка ошибок в запросе (корректно ли составлен запрос), разграничение доступа к данным (вдруг этого вам знать не следует) и валидация входящих данных (вдруг вы написали ерунду), в общем, всеми возможными проверками, которые сервер выполняет перед тем, как выполнить желание клиента.

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


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

Пример: GET /api/v1/users/25/name

Независимость формата хранения данных от формата их передачи — сервер может поддерживать несколько различных форматов для передачи одних и тех же данных (JSON, XML и т.д.), но хранит данные в своем внутреннем формате, независимо от поддерживаемых.

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

Чего нам не хватает

Классический REST подразумевает работу клиента с сервером как с плоским хранилищем данных, при этом ничего не говорится о связанности и взаимозависимости данных между собой. Все это по умолчанию целиком ложится на плечи клиентского приложения. Однако современные предметные области, для которых разрабатываются системы управления данными, будь то социальные сервисы или системы интернет-маркетинга, подразумевают сложную взаимосвязь между сущностями, хранящимися в базе данных. Поддержка этих связей, т.е. целостности данных, находится в зоне ответственности серверной стороны, в то время, как клиент является только интерфейсом для доступа к этим данным. Так чего же нам не хватает в REST?

Вызовы функций

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

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

Еще вариант – создание и разрыв связей между данными. Например, добавление пользователя в группу. Вызываем у сущности группа функцию addUser, в качестве параметра передаем объект пользователь, получаем результат.

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

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

Множественные операции

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

Для web API, стремящегося к идеалу, тоже хотелось бы как-то привести подобные операции в систему. Постараюсь сделать это в одном из продолжений.

Статистические запросы, агрегаторы, форматирование данных

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

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

Разновидности данных

Объекты

Ключевым типом данных в общении между клиентом и сервером выступает объект. По сути, объект – это перечень свойств и соответствующих им значений. Мы можем отправить объект на сервер в запросе и получить в результат запроса в виде объекта. При этом объект не обязательно будет реальной сущностью, хранящейся в базе данных, по крайней мере, в том виде, в котором он отправлен или получен. Например, учетные данные для авторизации передаются в виде объекта, но не являются самостоятельной сущностью. Даже хранимые в БД объекты склонны обрастать дополнительными свойствами внутрисистемного характера, например, датами создания и редактирования, различными системными метками и флагами. Свойства объектов могут быть как собственными скалярными значениями, так и содержать связанные объекты и коллекции объектов, которые не являются частью объекта. Часть свойств объектов может быть редактируемой, часть системной, доступной только для чтения, а часть может носить статистический характер и вычисляться на лету (например, количество лайков). Некоторые свойства объекта могут быть скрыты, в зависимости от прав пользователя.

Коллекции объектов

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

Скалярные значения

В чистом виде скалярные значения как отдельная сущность на моей памяти встречались крайне редко. Обычно они фигурировали как свойства объектов или коллекций, и в этом качестве они могут быть доступны как для чтения, так и для записи. Например, имя пользователя может быть получено и изменено в индивидуальном порядке GET /users/1/name . На практике эта возможность пригождается редко, но в случае необходимости хотелось бы, чтобы она была под рукой. Особенно это касается свойств коллекции, например числа записей (с фильтрацией или без нее): GET /news/count .

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

Приближение второе: Правильный путь

В этом приближении я хотел бы отдельно поговорить о подходах к построению уникальных путей к ресурсам и методам вашего web API и о тех архитектурных особенностях приложения, которые влияют на внешний вид этого пути и его компоненты.

О чем стоит подумать, стоя на берегу

Версионность

Рано или поздно любая действующая система начинает эволюционировать: развиваться, усложняться, масштабироваться, усовремениваться. Для разработчиков REST API это чревато в первую очередь тем, что необходимо запускать новые версии API при работающих старых. Здесь я говорю больше не об архитектурных изменениях под капотом вашей системы, а о том, что изменяется сам формат данных и набор операций с ними. В любом случае версионность нужно предусмотреть как в изначальной организации исходного кода, так и в принципе построения URL. Что касается URL, здесь существует два наиболее популярных способа указания версии API, которой адресован запрос. Префиксация пути example-api.com/v1/ и разведение версий на уровне субдомена v1.example-api.com . Использовать можно любой из них, в зависимости от потребности и необходимости.

Автономность компонентов

Web API сложных систем, поддерживающих несколько пользовательских ролей, зачастую требует разделения на части, каждая из которых обслуживает свой спектр задач. По сути, каждая часть может быть самостоятельным приложением, работать на разных физических машинах и платформах. В контексте описания API нам совершенно не важно, как сервер обрабатывает запрос и какие силы и технологии в этом замешаны. Для клиента API – система инкапсулированная. Тем не менее разные части системы могут обладать совершенно разной функциональностью, например, административная и пользовательская часть. И методология работы с одними и теми же, казалось бы, ресурсами может существенно отличаться. Поэтому такие части необходимо разделять на уровне домена admin.v1.example-api.com или префикса пути example-api.com/v1/admin/ . Это требование не является обязательным, и многое зависит от сложности системы и её назначения.

Формат обмена данными

Самым удобным и функциональным, на мой взгляд, форматом обмена данными является JSON, но никто не запрещает использовать XML, YAML или любой другой формат, позволяющий хранить сериализованные объекты без потери типа данных. При желании можно сделать в API поддержку нескольких форматов ввода/вывода. Достаточно задействовать HTTP заголовок запроса для указания желаемого формата ответа Accept и Content-Type для указания формата переданных в запросе данных. Другим популярным способом является добавление расширения к URL ресурса, например, GET /users.xml , но такой способ кажется менее гибким и красивым, хотя бы потому, что утяжеляет URL и верен скорее для GET-запросов, нежели для всех возможных операций.

Локализация и многоязычность

На практике многоязычность API чаще всего сводится к переводу сервисных сообщений и сообщений об ошибках на требуемый язык для прямого отображения конечному пользователю. Многоязычный контент тоже имеет место быть, но сохранение и выдача контента на разных языках, на мой взгляд, должна разграничиваться более явно, например, если у вас одна и та же статья существует на разных языках, то по факту это две разных сущности, сгруппированные по признаку единства содержания. Для идентификации ожидаемого языка можно использовать разные способы. Самым простым можно считать стандартный HTTP-заголовок Accept-Language . Я встречал и другие способы, такие, как добавление GET-параметра language=»en» , использование префикса пути example-api.com/en/ или даже на уровне доменного имени en.example-api.com . Мне кажется, что выбор способа указания локали зависит от конкретного приложения и задач, стоящих перед ним.

Внутренняя маршрутизация

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

Пути к коллекциям

Для указания пути к коллекции мы просто используем название соответствующей сущности, например, если это список пользователей, то путь будет таким /users . К коллекции как таковой применимы два метода: GET (получение лимитированного списка сущностей) и POST (создание нового элемента). В запросах на получение списков мы можем использовать множество дополнительных GET параметров, применяемых для постраничного вывода, сортировки, фильтрации, поиска etc, но они должны быть опциональными, т.е. эти параметры не должны передаваться как часть пути!

Элементы коллекции

Для обращения к конкретному элементу коллекции мы используем в маршруте его уникальный идентификатор /users/25 . Это и есть уникальный путь к нему. Для работы с объектом применимы методы GET (получение объекта), PUT/PATCH (изменение) и DELETE (удаление).

Уникальные объекты

Во множестве сервисов существуют уникальные для текущего пользователя объекты, например профиль текущего пользователя /profile , или персональные настройки /settings . Разумеется, с одной стороны, это элементы одной из коллекций, но они являются отправной точкой в использовании нашего Web API клиентским приложением, и к тому же позволяют намного более широкий спектр операций над данными. При этом коллекция, хранящая пользовательские настройки может быть вообще недоступна из соображений безопасности и конфиденциальности данных.

Свойства объектов и коллекций

Для того, чтобы добраться до любого из свойств объекта напрямую, достаточно добавить к пути до объекта имя свойства, например получить имя пользователя /users/25/name . К свойству применимы методы GET (получение значения) и PUT/PATCH (изменение значения). Метод DELETE не применим, т.к. свойство является структурной частью объекта, как формализованной единицы данных.

В предыдущей части мы говорили о том, что у коллекций, как и у объектов, могут быть собственные свойства. На моей памяти мне пригодилось только свойство count, но ваше приложение может быть более сложным и специфичным. Пути к свойствам коллекций строятся по тому же принципу, что и к свойствам их элементов: /users/count . Для свойств коллекций применим только метод GET (получение свойства), т.к. коллекция – это только интерфейс для доступа к списку.

Коллекции связанных объектов

Одной из разновидностей свойств объектов могут быть связанные объекты или коллекции связанных объектов. Такие сущности, как правило, не являются собственным свойством объекта, а лишь отсылками к его связям с другими сущностями. Например, перечень ролей, которые были присвоены пользователю /users/25/roles . По поводу работы с вложенными объектами и коллекциями мы подробно поговорим в одной из следующих частей, а на данном этапе нам достаточно того, что мы имеем возможность обращаться к ним напрямую, как к любому другому свойству объекта.

Функции объектов и коллекций


Для построения пути к интерфейсу вызова функции у коллекции или объекта мы используем тот же самый подход, что и для обращения к свойству. Например, для объекта /users/25/sendPasswordReminder или коллекции /users/disableUnconfirmed . Для вызовов функций мы в любом случае используем метод POST. Почему? Напомню, что в классическом REST не существует специального глагола для вызова функций, а потому нам придется использовать один из существующих. На мой взгляд, для этого больше всего подходит метод POST т.к. он позволяет передавать на сервер необходимые аргументы, не является идемпотентным (возвращающим один и тот же результат при многократном обращении) и наиболее абстрактен по семантике.

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

Приближение третье: Запросы и ответы

В предыдущих приближениях я рассказал о том, как пришла идея собрать и обобщить имеющийся опыт разработки web API. В первой части я постарался описать, с какими видами ресурсов и операций над ними мы имеем дело при проектировании web API. Во второй части были затронуты вопросы построения уникальных URL для обращения к этим ресурсам. А в этом приближении я попробую описать возможные варианты запросов и ответов.

Универсальный ответ

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

Success — маркер успешности выполнения запроса

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

Error — сведения об ошибке

В случае, если выполнение запроса завершилось неудачей — о причинах и разновидностях отрицательных ответов сервера поговорим чуть позже, — к ответу добавляется атрибут «error», содержащий в себе HTTP-код статуса и текст сообщения об ошибке. Прошу не путать с сообщениями об ошибках валидации данных для конкретных полей. Правильнее всего, на мой взгляд, возвращать код статуса и в заголовке ответа, но я встречал и другой подход — в заголовке всегда возвращать статус 200 (успех), а детали и возможные данные об ошибках передавать в теле ответа.

Data — данные, возвращаемые сервером

Большинство ответов сервера призваны возвращать данные. В зависимости от типа запроса и его успеха ожидаемый набор данных будет разным, тем не менее атрибут«data» будет присутствовать в подавляющем большинстве ответов.

Пример возвращаемых данных в случае успеха. В данном случае ответ содержит запрашиваемый объект user.

Пример возвращаемых данных в случае ошибки. В данном случае содержит имена полей и сообщения об ошибках валидации.

Pagination — сведения, необходимые для организации постраничной навигации

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

Минимальный набор значений для пагинации состоит из:

  • общего числа записей;
  • числа страниц;
  • номера текущей страницы;
  • числа записей на странице;
  • максимального числа записей на странице, поддерживаемого серверной стороной.

Некоторые разработчики web API также включают в пагинацию набор готовых ссылок на соседние страницы, а также первую, последнюю и текущую.

Илон Маск рекомендует:  Функции hyperwave

Работа над ошибками

Как уже упоминалось выше, не все запросы к web API завершаются успехом, но это тоже часть игры. Система информирования об ошибках является мощным инструментом, облегчающим работу клиента и направляющим клиентское приложение по правильному пути. Слово «ошибка» в этом контексте не совсем уместно. Здесь больше подойдёт слово исключение, так как на самом деле запрос успешно получен, проанализирован, и на него возвращается адекватный ответ, объясняющий, почему запрос не может быть выполнен.

Каковы же потенциальные причины получаемых исключений?

500 Internal server error — всё сломалось, но мы скоро починим

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

400 Bad request — а теперь у вас всё сломалось

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

401 Unauthorized — незнакомец, назови себя

Для доступа к этому ресурсу требуется авторизация. Разумеется, наличие авторизации не гарантирует того, что ресурс станет доступным, но не авторизовавшись, вы точно этого не узнаете. Возникает, например, при попытке обратиться к закрытой части API или при истечении срока действия текущего токена.

403 Forbidden — вам сюда нельзя

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

404 Not found — по этому адресу никто не живёт

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

405 Method not allowed — нельзя такое делать

Эта разновидность исключения напрямую связана с использованным при запросе глаголом (GET, PUT, POST, DELETE), который, в свою очередь, свидетельствует о действии, которое мы пытаемся совершить с ресурсом. Если запрошенный ресурс не поддерживает указанное действие, сервер говорит об этом прямо.

422 Unprocessable entity — исправьте и пришлите снова

Одно из самых полезных исключений. Возвращается каждый раз, когда в данных запроса существуют логические ошибки. Под данными запроса мы подразумеваем либо набор параметров и соответствующих им значений, переданных методом GET, либо поля объекта, передаваемого в теле запроса методами POST, PUT и DELETE. Если данные не прошли валидацию, сервер в секции «data» возвращает отчет о том, какие именно параметры невалидны и почему.

Протокол HTTP поддерживает намного большее число различных статус-кодов на все случаи жизни, но на практике они используются редко и в контексте web API не несут практической пользы. На моей памяти мне не приходилось выходить за пределы вышеперечисленного списка исключений.

Запросы

Получение элементов коллекции

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

Постраничная навигация

page — параметр указывает на то, какая страница должна быть отображена. Если этот параметр не передан, то отображается первая страница. Из первого же успешного ответа сервера будет ясно, сколько страниц имеет коллекция при текущих параметрах фильтрации. Если значение превышает максимальное число страниц, то разумнее всего вернуть ошибку 404 Not found.

perPage — указывает на желаемое число элементов на странице. Как правило, API имеет собственное значение по умолчанию, которое возвращает в качестве поля perPage в секции pagination, но в ряде случаев позволяет увеличивать это значение до разумных пределов, предоставив максимальное значение maxPerPage:

Сортировка результатов

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

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

В некоторых API это предлагается сделать в виде строки:

В других вариантах предлагается использовать массив:

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

Простая фильтрация по значению


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

Усложнённые варианты фильтрации

Многие интерфейсы требуют более сложной системы фильтрации и поиска. Перечислю основные и наиболее часто встречаемые варианты фильтрации.

Фильтрация по верхней и нижней границе с использованием операторов сравнения from (больше или равно), higher (больше), to (меньше или равно), lower (меньше). Применяется к полям, значения которых поддаются ранжированию.

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

Фильтрация по частичному совпадению строки. Применяется к полям, содержащим текстовые данные или данные, которые могут быть приравнены к текстовым, например, числовые артикулы товаров, номера телефонов и т. д.

Именованные фильтры

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

Именованные фильтры могут также иметь свои параметры.

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

За перевод материала выражаем благодарность международной IT-компании Noveo.

зМБЧБ 1
JavaScript. пВЪПТ.

ьФП ЧЧЕДЕОЙЕ Ч JavaScript Й ПВУХЦДЕОЙЕ ОЕЛПФПТЩИ ЖХОДБНЕОФБМШОЩИ РПОСФЙК.

ч ЗМБЧЕ ЙНЕАФУС УМЕДХАЭЙЕ ТБЪДЕМЩ:

юФП фБЛПЕ JavaScript?

JavaScript ЬФП УПЪДБООЩК ЖЙТНПК Netscape НЕЦРМБФЖПТНЕООЩК, ПВЯЕЛФОП-ПТЙЕОФЙТПЧБООЩК СЪЩЛ УЛТЙРФЙОЗБ (УГЕОБТЙЕЧ). сДТП JavaScript УПДЕТЦЙФ ОБВПТ ПУОПЧОЩИ ПВЯЕЛФПЧ, ФБЛЙИ ЛБЛ Array , Date Й Math , Й ПУОПЧОПК ОБВПТ ЬМЕНЕОФПЧ СЪЩЛБ, ФБЛЙИ ЛБЛ ПРЕТБГЙЙ, УФТХЛФХТЩ ХРТБЧМЕОЙС Й ПРЕТБФПТЩ. сДТП JavaScript НПЦЕФ ВЩФШ ТБУЫЙТЕОП ДМС ТБЪМЙЮОЩИ ГЕМЕК РХФЈН ДПРПМОЕОЙС ОПЧЩНЙ ПВЯЕЛФБНЙ; ОБРТЙНЕТ:

  • лМЙЕОФУЛЙК JavaScript ТБУЫЙТСЕФ СДТП СЪЩЛБ, РТЕДПУФБЧМСС ПВЯЕЛФЩ ХРТБЧМЕОЙС ВТБХЪЕТПН (Navigator ЙМЙ ДТХЗПК web-ВТБХЪЕТ) Й Document Object Model (DOM). оБРТЙНЕТ, ЛМЙЕОФУЛЙЕ ТБУЫЙТЕОЙС ДБАФ РТЙМПЦЕОЙА ЧПЪНПЦОПУФШ ТБЪНЕЭБФШ ЬМЕНЕОФЩ Ч HTML-ЖПТНЕ Й ТЕБЗЙТПЧБФШ ОБ ДЕКУФЧЙС РПМШЪПЧБФЕМС, ФБЛЙЕ ЛБЛ ЭЕМЮПЛ НЩЫЙ, ЧЧПД ДБООЩИ Ч ЖПТНХ Й ОБЧЙЗБГЙС РП УФТБОЙГБН.
  • уЕТЧЕТОЩК JavaScript ТБУЫЙТСЕФ СДТП СЪЩЛБ, РТЕДПУФБЧМСС ПВЯЕЛФЩ, ПФОПУСЭЙЕУС Л ЪБРХУЛХ JavaScript ОБ УЕТЧЕТЕ. оБРТЙНЕТ, УЕТЧЕТОЩЕ ТБУЫЙТЕОЙС ДБАФ РТЙМПЦЕОЙА ЧПЪНПЦОПУФШ УПЕДЙОСФШУС У ТЕМСГЙПООПК вд, УПИТБОСФШ ЙОЖПТНБГЙА НЕЦДХ ЧЩЪПЧБНЙ РТЙМПЦЕОЙС ЙМЙ ЧЩРПМОСФШ ТБВПФХ У ЖБКМБНЙ ОБ УЕТЧЕТЕ.

JavaScript РПЪЧПМСЕФ УПЪДБЧБФШ РТЙМПЦЕОЙС, ТБВПФБАЭЙЕ РП ЧУЕК УЕФЙ Internet. лМЙЕОФУЛЙЕ РТЙМПЦЕОЙС ТБВПФБАФ Ч ВТБХЪЕТЕ, ФБЛПН ЛБЛ Netscape Navigator, Б УЕТЧЕТОЩЕ РТЙМПЦЕОЙС — ОБ УЕТЧЕТЕ, ФБЛПН ЛБЛ Netscape Enterprise Server. йУРПМШЪХС JavaScript, чЩ НПЦЕФЕ УПЪДБЧБФШ ДЙОБНЙЮЕУЛЙЕ HTML-УФТБОЙГЩ, ПВТБВБФЩЧБАЭЙЕ РПМШЪПЧБФЕМШУЛЙК ЧЧПД Й ЙНЕАЭЙЕУС ДБООЩЕ, ЙУРПМШЪХС УРЕГЙБМШОЩЕ ПВЯЕЛФЩ, ЖБКМЩ Й ТЕМСГЙПООЩЕ вд.

у РПНПЭША ЖХОЛГЙПОБМШОПУФЙ JavaScript LiveConnect чЩ НПЦЕФЕ ПТЗБОЙЪПЧБФШ ЧЪБЙНПДЕКУФЧЙЕ ЛПДПЧ Java Й JavaScript. йЪ JavaScript чЩ НПЦЕФЕ ЙОУФБОГЙЙТПЧБФШ ПВЯЕЛФЩ Java Й РПМХЮБФШ ДПУФХР Л ЙИ public-НЕФПДБН Й РПМСН. йЪ Java чЩ НПЦЕФЕ РПМХЮБФШ ДПУФХР Л ПВЯЕЛФБН, УЧПКУФЧБН Й НЕФПДБН JavaScript.

лПТРПТБГЙС Netscape ЙЪПВТЕМБ JavaScript, Й JavaScript ВЩМ ЧРЕТЧЩЕ ЙУРПМШЪПЧБО Ч ВТБХЪЕТБИ Netscape.

сДТП, лМЙЕОФУЛЙК Й уЕТЧЕТОЩК JavaScript

лПНРПОЕОФЩ JavaScript РПЛБЪБОЩ ОБ ТЙУХОЛЕ:

тЙУХОПЛ 1.1 сЪЩЛ JavaScript

ч УМЕДХАЭЕН ТБЪДЕМЕ ТБЪВЙТБЕФУС ТБВПФБ JavaScript ОБ УФПТПОЕ ЛМЙЕОФБ Й ОБ УЕТЧЕТЕ.

сДТП JavaScript

лМЙЕОФУЛЙК Й УЕТЧЕТОЩК JavaScript ЙНЕАФ УМЕДХАЭЙЕ ПВЭЙЕ ЬМЕНЕОФЩ:

  • лМАЮЕЧЩЕ УМПЧБ
  • уЙОФБЛУЙУ ПРЕТБФПТПЧ Й ЗТБННБФЙЛХ
  • рТБЧЙМБ ОБРЙУБОЙС ЧЩТБЦЕОЙК, РЕТЕНЕООЩИ Й МЙФЕТБМПЧ
  • мЕЦБЭХА Ч ПУОПЧЕ ПВЯЕЛФОХА НПДЕМШ (ИПФС ЛМЙЕОФУЛЙК Й УЕТЧЕТОЩК JavaScript ЙНЕАФ ТБЪОЩЕ РТЕДПРТЕДЕМЈООЩЕ ПВЯЕЛФЩ)
  • рТЕДПРТЕДЕМЈООЩЕ ПВЯЕЛФЩ Й ЖХОЛГЙЙ, ФБЛЙЕ ЛБЛ Array , Date Й Math

лМЙЕОФУЛЙК JavaScript

Web-ВТБХЪЕТЩ, ФБЛЙЕ ЛБЛ Navigator (2.0 Й ВПМЕЕ РПЪДОЙЕ ЧЕТУЙЙ) НПЗХФ ЙОФЕТРТЕФЙТПЧБФШ ПРЕТБФПТЩ ЛМЙЕОФУЛПЗП JavaScript, ЧОЕДТЈООЩЕ Ч HTML-УФТБОЙГХ. лПЗДБ ВТБХЪЕТ (ЙМЙ ЛМЙЕОФ) ЪБРТБЫЙЧБЕФ ФБЛХА УФТБОЙГХ, УЕТЧЕТ ЧЩУЩМБЕФ ЛМЙЕОФХ РП УЕФЙ РПМОПЕ УПДЕТЦЙНПЕ ДПЛХНЕОФБ, ЧЛМАЮБС HTML Й ПРЕТБФПТЩ JavaScript. вТБХЪЕТ ЮЙФБЕФ УФТБОЙГХ УЧЕТИХ ЧОЙЪ, ПФПВТБЦБС ТЕЪХМШФБФ ТБВПФЩ HTML Й ЧЩРПМОСС ПРЕТБФПТЩ JavaScript РП НЕТЕ ЙИ ПВОБТХЦЕОЙС. ьФПФ РТПГЕУУ, РТПЙММАУФТЙТПЧБООЩК ОБ ТЙУХОЛЕ, РТПЙЪЧПДЙФ ТЕЪХМШФБФ, ЛПФПТЩК ЧЙДЙФ РПМШЪПЧБФЕМШ.

тЙУХОПЛ 1.2 лМЙЕОФУЛЙК JavaScript

пРЕТБФПТЩ ЛМЙЕОФУЛПЗП JavaScript, ЧУФТПЕООПЗП Ч HTML-УФТБОЙГХ, НПЗХФ ТЕБЗЙТПЧБФШ ОБ РПМШЪПЧБФЕМШУЛЙЕ УПВЩФЙС, ФБЛЙЕ ЛБЛ ЭЕМЮПЛ НЩЫЙ, ЧЧПД ДБООЩИ Ч ЖПТНХ Й ОБЧЙЗБГЙС РП УФТБОЙГБН. оБРТЙНЕТ, чЩ НПЦЕФЕ ОБРЙУБФШ ЖХОЛГЙА JavaScript ДМС РТПЧЕТЛЙ ЧЧПДБ РПМШЪПЧБФЕМЕН РТБЧЙМШОПК ЙОЖПТНБГЙЙ Ч ЖПТНХ, ЪБРТБЫЙЧБАЭХА ФЕМЕЖПООЩК ОПНЕТ ЙМЙ zip-ЛПД. вЕЪ РЕТЕДБЮЙ РП УЕФЙ ЧОЕДТЈООЩК JavaScript ОБ HTML-УФТБОЙГЕ НПЦЕФ РТПЧЕТЙФШ ЧЧЕДЈООЩЕ ДБООЩЕ Й ЧЩЧЕУФЙ ДЙБМПЗПЧПЕ ПЛОП, ЕУМЙ РПМШЪПЧБФЕМШ ЧЧЈМ ОЕЧЕТОЩЕ ДБООЩЕ.

тБЪОЩЕ ЧЕТУЙЙ JavaScript ТБВПФБАФ УП УРЕГЙЖЙЮЕУЛЙНЙ ЧЕТУЙСНЙ Navigator’Б. оБРТЙНЕТ, JavaScript 1.2 ТБВПФБЕФ У Navigator 4.0. оЕЛПФПТЩЕ ЧПЪНПЦОПУФЙ JavaScript 1.2 ОЕДПУФХРОЩ Ч JavaScript 1.1 Й РПЬФПНХ ОЕДПУФХРОЩ Ч Navigator 3.0. йОЖПТНБГЙА П ЧЕТУЙСИ JavaScript Й Navigator УН. Ч ТБЪДЕМЕ «чЕТУЙЙ JavaScript».

уЕТЧЕТОЩК JavaScript

оБ УЕТЧЕТЕ чЩ ФБЛЦЕ НПЦЕФЕ ЧОЕДТСФШ JavaScript Ч HTML-УФТБОЙГЩ. уЕТЧЕТОЩЕ ПРЕТБФПТЩ НПЗХФ УПЕДЙОСФШУС У ТЕМСГЙПООЩНЙ вд ТБЪОЩИ РТПЙЪЧПДЙФЕМЕК, ТБЪДЕМСФШ ЙОЖПТНБГЙА НЕЦДХ РПМШЪПЧБФЕМСНЙ РТЙМПЦЕОЙС, РПМХЮБФШ ДПУФХР Л ЖБКМПЧПК УЙУФЕНЕ УЕТЧЕТБ ЙМЙ ЧЪБЙНПДЕКУФЧПЧБФШ У ДТХЗЙНЙ РТЙМПЦЕОЙСНЙ ЮЕТЕЪ LiveConnect Й Java. HTML-УФТБОЙГЩ У УЕТЧЕТОЩН JavaScript НПЗХФ УПДЕТЦБФШ ФБЛЦЕ ЛМЙЕОФУЛЙК JavaScript.

ч ПФМЙЮЙЕ ПФ УФТБОЙГ У ЮЙУФП ЛМЙЕОФУЛЙН JavaScript, HTML-УФТБОЙГЩ, ЙУРПМШЪХАЭЙЕ УЕТЧЕТОЩК JavaScript, ЛПНРЙМЙТХАФУС Ч ВБКФ-ЛПДПЧЩЕ ЙУРПМОСЕНЩЕ ЖБКМЩ. ьФЙ ЙУРПМОСЕНЩЕ РТЙМПЦЕОЙС ЪБРХУЛБАФУС ОБ ЧЩРПМОЕОЙЕ web-УЕТЧЕТПН, ЙНЕАЭЙН НБЫЙОХ ЧТЕНЕОЙ ЧЩРПМОЕОЙС JavaScript. йУИПДС ЙЪ ЬФПЗП, УПЪДБОЙЕ РТЙМПЦЕОЙК JavaScript ЬФП РТПГЕУУ ЙЪ ДЧХИ ЬФБРПЧ.

оБ РЕТЧПН ЬФБРЕ, РПЛБЪБООПН ОБ тЙУХОЛЕ 1.3, чЩ УПЪДБЈФЕ HTML-УФТБОЙГЩ (ЛПФПТЩЕ НПЗХФ УПДЕТЦБФШ ПРЕТБФПТЩ ЛБЛ ЛМЙЕОФУЛПЗП, ФБЛ Й УЕТЧЕТОПЗП JavaScript) Й ЖБКМЩ JavaScript. ъБФЕН чЩ ЛПНРЙМЙТХЕФЕ ЧУЕ ЬФЙ ЖБКМЩ Ч ЕДЙОЩК ЙУРПМОСЕНЩК ВМПЛ.

тЙУХОПЛ 1.3 уЕТЧЕТОЩК JavaScript Ч РТПГЕУУЕ ТБЪТБВПФЛЙ

оБ ЧФПТПН ЬФБРЕ, РПЛБЪБООПН ОБ тЙУХОЛЕ 1.4, УФТБОЙГБ РТЙМПЦЕОЙС ЪБРТБЫЙЧБЕФУС ЛМЙЕОФУЛЙН ВТБХЪЕТПН. нБЫЙОБ ЧЩРПМОЕОЙС ЙУРПМШЪХЕФ ЙУРПМОСЕНЩК ВМПЛ ДМС РТПУНПФТБ ЙУИПДОПК УФТБОЙГЩ Й ДЙОБНЙЮЕУЛПК ЗЕОЕТБГЙЙ HTML-УФТБОЙГЩ, ЧПЪЧТБЭБЕНПК ЛМЙЕОФХ. пОБ ЧЩРПМОСЕФ ЧУЕ ОБКДЕООЩЕ ОБ УФТБОЙГЕ ПРЕТБФПТЩ УЕТЧЕТОПЗП JavaScript. чЩРПМОЕОЙЕ ЬФЙИ ПРЕТБФПТПЧ НПЦЕФ ДПВБЧЙФШ ОПЧЩЕ ПРЕТБФПТЩ HTML ЙМЙ ПРЕТБФПТЩ ЛМЙЕОФУЛПЗП JavaScript Ч HTML-УФТБОЙГХ. нБЫЙОБ ЧЩРПМОЕОЙС ПФУЩМБЕФ ЪБФЕН ПЛПОЮБФЕМШОЩК ЧБТЙБОФ УФТБОЙГЩ РП УЕФЙ Navigator-ЛМЙЕОФХ, ЛПФПТЩК ЧЩРПМОСЕФ ЛМЙЕОФУЛЙК JavaScript Й ПФПВТБЦБЕФ ТЕЪХМШФБФ.

тЙУХОПЛ 1.4 уЕТЧЕТОЩК JavaScript Ч РТПГЕУУЕ ЧЩРПМОЕОЙС

ч ПФМЙЮЙЕ ПФ УФБОДБТФОЩИ РТПЗТБНН Common Gateway Interface (CGI), ЧУЕ ЙУИПДОЙЛЙ JavaScript ЙОФЕЗТЙТПЧБОЩ ОЕРПУТЕДУФЧЕООП Ч HTML-УФТБОЙГЩ, ХУЛПТСС ТБЪТБВПФЛХ Й ПВМЕЗЮБС ПВУМХЦЙЧБОЙЕ. уМХЦВБ Session Management Service УЕТЧЕТОПЗП JavaScript УПДЕТЦЙФ ПВЯЕЛФЩ, ЛПФПТЩЕ чЩ НПЦЕФЕ ЙУРПМШЪПЧБФШ ДМС ТБВПФЩ У ДБООЩНЙ, УХЭЕУФЧХАЭЙНЙ НЕЦДХ ЛМЙЕОФУЛЙНЙ ЪБРТПУБНЙ, Х ОЕУЛПМШЛЙИ ЛМЙЕОФПЧ ЙМЙ ОЕУЛПМШЛЙИ РТЙМПЦЕОЙК. уМХЦВБ LiveWire Database Service УЕТЧЕТОПЗП JavaScript РТЕДПУФБЧМСЕФ ПВЯЕЛФЩ ДМС ДПУФХРБ Л вд, УМХЦБЭЙЕ ЙОФЕТЖЕКУПН ДМС УЕТЧЕТПЧ Structured Query Language (SQL).

JavaScript Й Java

JavaScript Й Java ОБРПНЙОБАФ ДТХЗ ДТХЗБ, ОП ЙНЕАФ Й ЖХОДБНЕОФБМШОЩЕ ПФМЙЮЙС. JavaScript ОЕ ЙНЕЕФ УФБФЙЮЕУЛПК ФЙРЙЪБГЙЙ Й УФТПЗПК РТПЧЕТЛЙ ФЙРПЧ Java. JavaScript РПДДЕТЦЙЧБЕФ ВПМШЫХА ЮБУФШ УЙОФБЛУЙУБ ЧЩТБЦЕОЙК Java Й ВБЪПЧЩЕ ЛПОУФТХЛГЙЙ ХРТБЧМЕОЙС РПФПЛПН.

ч ПФМЙЮЙЕ ПФ УЙУФЕНЩ ЧТЕНЕОЙ ЛПНРЙМСГЙЙ Java, РПУФТПЕООПК ОБ ПВЯСЧМЕОЙСИ, JavaScript РПДДЕТЦЙЧБЕФ УЙУФЕНХ ЧТЕНЕОЙ ЧЩРПМОЕОЙС, ПУОПЧБООХА ОБ ОЕВПМШЫПН ЛПМЙЮЕУФЧЕ ФЙРПЧ ДБООЩИ: ЮЙУМПЧЩИ, вХМЕЧЩИ Й УФТПЛПЧЩИ. JavaScript ЙНЕЕФ ПВЯЕЛФОХА НПДЕМШ ОБ ВБЪЕ РТПФПФЙРПЧ ЧНЕУФП ВПМЕЕ ПВЭЕК ПВЯЕЛФОПК НПДЕМЙ ОБ ВБЪЕ ЛМБУУПЧ. нПДЕМШ ОБ ВБЪЕ РТПФПФЙРПЧ РТЕДПУФБЧМСЕФ ЧПЪНПЦОПУФШ ДЙОБНЙЮЕУЛПЗП ОБУМЕДПЧБОЙС; ФП ЕУФШ, ФП, ЮФП ОБУМЕДХЕФУС, НПЦЕФ ПФМЙЮБФШУС ДМС ТБЪОЩИ ПВЯЕЛФПЧ. JavaScript ФБЛЦЕ РПДДЕТЦЙЧБЕФ ЖХОЛГЙЙ ВЕЪ УРЕГЙБМШОЩИ ФТЕВПЧБОЙК ПВЯСЧМЕОЙС. жХОЛГЙЙ НПЗХФ ВЩФШ УЧПКУФЧБНЙ ПВЯЕЛФПЧ, ЙУРПМОСЕНЩНЙ ЛБЛ ОЕФЙРЙЪЙТПЧБООЩЕ НЕФПДЩ.

JavaScript ЬФП СЪЩЛ, УЧПВПДОЩК РП ЖПТНЕ, РП УТБЧОЕОЙА У Java. чЩ ОЕ ДПМЦОЩ ПВЯСЧМСФШ ЧУЕ РЕТЕНЕООЩЕ, ЛМБУУЩ Й НЕФПДЩ. чЩ ОЕ ДПМЦОЩ ХЮЙФЩЧБФШ, СЧМСАФУС МЙ НЕФПДЩ public, private ЙМЙ protected, Й ОЕ ПВСЪБОЩ ТЕБМЙЪПЧЩЧБФШ ЙОФЕТЖЕКУЩ. Return-ФЙРЩ РЕТЕНЕООЩИ, РБТБНЕФТПЧ Й ЖХОЛГЙК ОЕ ФЙРЙЪЙТПЧБОЩ СЧОП.

Java ЬФП СЪЩЛ ОБ ВБЪЕ ЛМБУУПЧ, ТБЪТБВПФБООЩК ДМС ВЩУФТПЗП ЧЩРПМОЕОЙС Й УФТПЗПК ФЙРЙЪБГЙЙ. уФТПЗБС ФЙРЙЪБГЙС ПЪОБЮБЕФ, Л РТЙНЕТХ, ЮФП чЩ ОЕ НПЦЕФЕ РТЙЧЕУФЙ/cast ГЕМПЕ ЮЙУМП Java (integer) Л УУЩМЛЕ ОБ ПВЯЕЛФ ЙМЙ РПМХЮЙФШ ДПУФХР Л private-РБНСФЙ, ОБТХЫБС ВБКФ-ЛПДЩ Java. нПДЕМШ Java ОБ ВБЪЕ ЛМБУУПЧ ПЪОБЮБЕФ, ЮФП РТПЗТБННЩ УПУФПСФ ЙУЛМАЮЙФЕМШОП ЙЪ ЛМБУУПЧ Й ЙИ НЕФПДПЧ. оБУМЕДПЧБОЙЕ ЛМБУУПЧ Ч Java Й УФТПЗБС ФЙРЙЪБГЙС ПВЩЮОП ФТЕВХАФ ФЕУОП ЧЩУФТПЕООПК ЙЕТБТИЙК ПВЯЕЛФПЧ. ьФЙ ФТЕВПЧБОЙС ДЕМБАФ РТПЗТБННЙТПЧБОЙЕ ОБ Java ВПМЕЕ УМПЦОЩН, ЮЕН БЧФПТЙЪБГЙС ОБ JavaScript.

ч РТПФЙЧПРПМПЦОПУФШ ЬФПНХ, JavaScript ЧЕДЈФ УЧПЈ ОБЮБМП ПФ ОЕВПМШЫЙИ ДЙОБНЙЮЕУЛЙ ФЙРЙЪЙТПЧБООЩИ СЪЩЛПЧ, ФБЛЙИ ЛБЛ HyperTalk Й dBASE. ьФЙ СЪЩЛЙ УГЕОБТЙЕЧ РТЕДПУФБЧМСАФ ХФЙМЙФЩ РТПЗТБННЙТПЧБОЙС ДМС ВПМЕЕ ЫЙТПЛПК БХДЙФПТЙЙ, РПУЛПМШЛХ ЙНЕАФ ПВМЕЗЮЈООЩК УЙОФБЛУЙУ, УРЕГЙБМЙЪЙТПЧБООХА ЧУФТПЕООХА ЖХОЛГЙПОБМШОПУФШ Й НЙОЙНБМШОЩЕ ФТЕВПЧБОЙС РТЙ УПЪДБОЙЙ ПВЯЕЛФПЧ.

фБВМЙГБ 1.1 JavaScript Ч УТБЧОЕОЙЙ У Java

йОФЕТРТЕФЙТХЕФУС (ОЕ ЛПНРЙМЙТХЕФУС) ЛМЙЕОФПН.


уЛПНРЙМЙТПЧБООЩЕ ВБКФ-ЛПДЩ, ЪБЗТХЦЕООЩЕ У УЕТЧЕТБ, ЧЩРПМОСАФУС ОБ ЛМЙЕОФЕ.

пВЯЕЛФОП-ПТЙЕОФЙТПЧБООЩК. оЕФ ПФМЙЮЙК НЕЦДХ ФЙРБНЙ ПВЯЕЛФПЧ. оБУМЕДПЧБОЙЕ ПУХЭЕУФЧМСЕФУС ЮЕТЕЪ НЕИБОЙЪН РТПФПФЙРПЧ, Б УЧПКУФЧБ Й НЕФПДЩ НПЗХФ ДПВБЧМСФШУС Л ПВЯЕЛФХ ДЙОБНЙЮЕУЛЙ.

оБ ВБЪЕ ЛМБУУПЧ. пВЯЕЛФЩ ДЕМСФУС ОБ ЛМБУУЩ Й ЬЛЪЕНРМСТЩ, ОБУМЕДХАЭЙЕ РП ЧУЕК ГЕРЙ ЙЕТБТИЙЙ ЛМБУУПЧ. лМБУУЩ Й ЬЛЪЕНРМСТЩ ОЕ НПЗХФ ЙНЕФШ УЧПКУФЧБ Й НЕФПДЩ, ДПВБЧМСЕНЩЕ ДЙОБНЙЮЕУЛЙ.

лПДЩ ЙОФЕЗТЙТПЧБОЩ Й ЧОЕДТЕОЩ Ч HTML.

бРМЕФЩ ПФМЙЮБАФУС ПФ HTML (ДПУФХР Л ОЙН ПУХЭЕУФЧМСЕФУС ЙЪ HTML-УФТБОЙГ).

фЙРЩ РЕТЕНЕООЩИ ОЕ ПВЯСЧМСАФУС (ДЙОБНЙЮЕУЛБС ФЙРЙЪБГЙС).

фЙРЩ РЕТЕНЕООЩИ ПВСЪБОЩ ВЩФШ ПВЯСЧМЕОЩ (УФБФЙЮЕУЛБС ФЙРЙЪБГЙС).

оЕ НПЦЕФ БЧФПНБФЙЮЕУЛЙ ЪБРЙУЩЧБФШ ОБ ЦЈУФЛЙК ДЙУЛ.

оЕ НПЦЕФ БЧФПНБФЙЮЕУЛЙ ЪБРЙУЩЧБФШ ОБ ЦЈУФЛЙК ДЙУЛ.

пФМБДЛБ Ч JavaScript

JavaScript РПЪЧПМСЕФ УПЪДБЧБФШ УМПЦОЩЕ ЛПНРШАФЕТОЩЕ РТПЗТБННЩ. лБЛ Й ЧП ЧУЕИ ДТХЗЙИ СЪЩЛБИ, чЩ НПЦЕФЕ ПЫЙВБФШУС РТЙ ОБРЙУБОЙЙ УЛТЙРФПЧ. пФМБДЮЙЛ Netscape JavaScript Debugger ДБЈФ ЧПЪНПЦОПУФШ ПФМБЦЙЧБФШ чБЫЙ УЛТЙРФЩ.

Visual JavaScript

Netscape Visual JavaScript ЬФП ХФЙМЙФБ ЧЙЪХБМШОПК ТБЪТБВПФЛЙ ОБ ВБЪЕ ЛПНРПОЕОФПЧ ДМС РМБФЖПТНЩ Netscape Open Network Environment (ONE). пО РЕТЧПОБЮБМШОП РТЕДОБЪОБЮБМУС ДМС ЙУРПМШЪПЧБОЙС ТБЪТБВПФЮЙЛБНЙ НЕЦРМБФЖПТНЕООЩИ УФБОДБТФЙЪПЧБООЩИ web-РТЙМПЦЕОЙК ЙЪ ЗПФПЧЩИ ЛПНРПОЕОФПЧ У НЙОЙНБМШОЩНЙ ЪБФТБФБНЙ ОБ РТПЗТБННЙТПЧБОЙЕ. ьФЙ РТЙМПЦЕОЙС ВБЪЙТХАФУС ОБ HTML, JavaScript Й Java.

JavaScript Й уРЕГЙЖЙЛБГЙС ECMA

Netscape ЙЪПВТЕМБ JavaScript, Й JavaScript ВЩМ ЧРЕТЧЩЕ ЙУРПМШЪПЧБО Ч ВТБХЪЕТБИ Netscape. пДОПЧТЕНЕООП Netscape ТБВПФБЕФ У ECMA (European Computer Manufacturers Association) ДМС УПЪДБОЙС УФБОДБТФЙЪПЧБООПЗП НЕЦДХОБТПДОПЗП СЪЩЛБ РТПЗТБННЙТПЧБОЙС ОБ ВБЪЕ СДТБ JavaScript. ECMA ЬФП НЕЦДХОБТПДОБС БУУПГЙБГЙС УФБОДБТФПЧ Ч ПВМБУФЙ УЙУФЕН ЙОЖПТНБГЙЙ Й ЛПННХОЙЛБГЙК. ьФБ УФБОДБТФЙЪПЧБООБС ЧЕТУЙС JavaScript, ОБЪЩЧБЕНБС ECMAScript, ЧЕДЈФ УЕВС УПЧЕТЫЕООП ПДЙОБЛПЧП ЧП ЧУЕИ РТЙМПЦЕОЙСИ, РПДДЕТЦЙЧБАЭЙИ ЬФПФ УФБОДБТФ. лПНРБОЙЙ НПЗХФ ЙУРПМШЪПЧБФШ ЬФПФ ПФЛТЩФЩК УФБОДБТФОЩК СЪЩЛ ДМС УПЪДБОЙС УЧПЙИ ТЕБМЙЪБГЙК JavaScript. рЕТЧБС ЧЕТУЙС УФБОДБТФБ ECMA ДПЛХНЕОФЙТПЧБОБ Ч УРЕГЙЖЙЛБГЙЙ ECMA-262.

уФБОДБТФ ECMA-262 ПДПВТЕО ФБЛЦЕ ISO (International Organization for Standards) ЛБЛ ISO-16262. чЩ НПЦЕФЕ ОБКФЙ PDF-ЧЕТУЙА ECMA-262 ОБ Netscape DevEdge Online. чЩ ФБЛЦЕ НПЦЕФЕ ОБКФЙ ЬФХ УРЕГЙЖЙЛБГЙА ОБ УБКФЕ ECMA. уРЕГЙЖЙЛБГЙС ECMA ОЕ ПРЙУЩЧБЕФ Document Object Model (DOM), ЛПФПТБС УФБОДБТФЙЪХЕФУС ЛПОУПТГЙХНПН World Wide Web Consortium (W3C). DOM ПРТЕДЕМСЕФ УРПУПВ, ЛПФПТЩН ПВЯЕЛФЩ HTML-ДПЛХНЕОФБ ЬЛУРПОЙТХАФУС Ч УЛТЙРФЕ.

уППФОПЫЕОЙЕ нЕЦДХ чЕТУЙСНЙ JavaScript Й ECMA

Netscape ФЕУОП УПФТХДОЙЮБЕФ У ECMA ДМС УПЪДБОЙС УРЕГЙЖЙЛБГЙЙ ECMA.

дЕФБМШОХА ЙОЖПТНБГЙА П УППФОПЫЕОЙЙ ЧЕТУЙК УРЕГЙЖЙЛБГЙК JavaScript Й ECMA УН. ОБ УБКФЕ mozilla.org.

JavaScript ЧУЕЗДБ ВХДЕФ УПДЕТЦБФШ ЧПЪНПЦОПУФЙ, ОЕ ЧЛМАЮЈООЩЕ Ч УРЕГЙЖЙЛБГЙА ECMA; JavaScript УПЧНЕУФЙН У ECMA, РТЕДПУФБЧМСС ДПРПМОЙФЕМШОЩЕ ЧПЪНПЦОПУФЙ.

дПЛХНЕОФБГЙС JavaScript Й уРЕГЙЖЙЛБГЙС ECMA

уРЕГЙЖЙЛБГЙС ECMA ЬФП ОБВПТ ФТЕВПЧБОЙК РП ТЕБМЙЪБГЙЙ ECMAScript; ПОБ РТЙНЕОЙНБ, ЕУМЙ чБН ОЕПВИПДЙНП ПРТЕДЕМЙФШ, РПДДЕТЦЙЧБЕФУС МЙ ЧПЪНПЦОПУФШ ЙЪ JavaScript Ч ECMA. еУМЙ чЩ РМБОЙТХЕФЕ ОБРЙУБФШ ЛПД JavaScript, ЙУРПМШЪХАЭЙК ФПМШЛП ЧПЪНПЦОПУФЙ, РПДДЕТЦЙЧБЕНЩЕ ECMA, чБН НПЦЕФ РПОБДПВЙФШУС РТПУНПФТЕФШ УРЕГЙЖЙЛБГЙА ECMA.

дПЛХНЕОФ ECMA ОЕ РТЕДОБЪОБЮЕО ДМС РПНПЭЙ РТПЗТБННЙУФБН УЛТЙРФПЧ; ДМС ЬФПЗП ЙУРПМШЪХКФЕ ДПЛХНЕОФБГЙА JavaScript.

JavaScript Й фЕИОПМПЗЙС ECMA

уРЕГЙЖЙЛБГЙС ECMA ЙУРПМШЪХЕФ ФЕТНЙОПМПЗЙА Й УЙОФБЛУЙУ, ЛПФПТЩЕ НПЗХФ ВЩФШ ОЕЪОБЛПНЩ РТПЗТБННЙУФБН JavaScript. иПФС ПРЙУБОЙЕ СЪЩЛБ НПЦЕФ ПФМЙЮБФШУС Ч ECMA, УБН СЪЩЛ ПУФБЈФУС ФЕН ЦЕ УБНЩН. JavaScript РПДДЕТЦЙЧБЕФ ЧУА ЖХОЛГЙПОБМШОПУФШ, ДБООХА Ч УРЕГЙЖЙЛБГЙЙ ECMA.

дПЛХНЕОФБГЙС РП JavaScript ПРЙУЩЧБЕФ БУРЕЛФЩ СЪЩЛБ, ОЕПВИПДЙНЩЕ РТПЗТБННЙУФХ ОБ JavaScript. оБРТЙНЕТ:

  • пВЯЕЛФ global ОЕ ПВУХЦДБЕФУС Ч ДПЛХНЕОФБГЙЙ JavaScript, РПУЛПМШЛХ чЩ ОЕ ЙУРПМШЪХЕФЕ ЕЗП СЧОП. нЕФПДЩ Й УЧПКУФЧБ ПВЯЕЛФБ global, ЙУРПМШЪХЕНПЗП чБНЙ, ПВУХЦДБАФУС Ч ДПЛХНЕОФБГЙЙ JavaScript, ОП ОБЪЩЧБАФУС ЖХОЛГЙСНЙ Й УЧПКУФЧБНЙ ЧЕТИОЕЗП ХТПЧОС.
  • лПОУФТХЛФПТ ВЕЪ РБТБНЕФТПЧ (zero-argument) У ПВЯЕЛФБНЙ Number Й String ОЕ ПВУХЦДБЕФУС Ч ДПЛХНЕОФБГЙЙ JavaScript, РПУЛПМШЛХ ФП, ЮФП ЗЕОЕТЙТХЕФУС, ЙУРПМШЪХЕФУС НБМП. Number -ЛПОУФТХЛФПТ ВЕЪ БТЗХНЕОФПЧ ЧПЪЧТБЭБЕФ +0, Б String -ЛПОУФТХЛФПТ ВЕЪ БТЗХНЕОФПЧ ЧПЪЧТБЭБЕФ «» (РХУФХА УФТПЛХ).
пЗМБЧМЕОЙЕ | оБЪБД | чРЕТЈД | йОДЕЛУ

дБФБ РПУМЕДОЕЗП ПВОПЧМЕОЙС: 29 УЕОФСВТС 1999 З.

© Copyright © 1999 Sun Microsystems, Inc. оЕЛПФПТБС ЮБУФШ Copyright © 1999 Netscape Communications Corp. чУЕ рТБЧБ ъБТЕЪЕТЧЙТПЧБОЩ.

Введение в программирование скриптов на C

Информация

Язык программирования C — это традиционный инструмент разработки программного обеспечения, используемый на протяжении последних 25 лет (с момента появления Unix). С учетом того, что Unix в настоящее время является основной серверной средой, умение программировать CGI -скрипты на C является одним из необходимых условий успешной работы Web-инженера.

Вникнув повнимательнее в спецификацию CGI , любой программист поймет, что спецификация создавалась с расчетом на Unix и С. Работа с переменными окружения и потоками стандартного ввода/вывода построена с учетом особенностей среды и средств программирования. При адаптации спецификации CGI в других средах, например, MS-Windows, программирование многих механизмов обмена приходится модифицировать.

Большинство задач при разработке скриптов можно решить средствами Perl, но есть ряд задач, которые требуют использования C-программ. Наиболее распространенным применением C являются скрипты-интерфейсы к базам данных. В качестве примера такого интерфейса воспользуемся библиотекой PostgreSQL.

В данном разделе речь пойдет о программировании CGI -скриптов на классическом C без объектно-ориентрованных особенностей C++.

Общая структура C-скрипта

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

При разработке С-скрипта следует всегда помнить, что в отличие от скрипта на Bash и Perl, С- скрипт , прежде чем выполнить, нужно еще и откомпилировать, т.е. превратить в исполняемый компьютером код. Если в системе нет компилятора для C, то программировать С-скрипты будет довольно сложно.

Синтаксически главная процедура выглядит следующим образом:

В этом фрагменте представлены все основные элементы программирования CGI -скриптов на С. Строки в начале программы ( #include. .. ) позволяют включить в текст программы декларации ( описатели ) стандартных функций. Строка » void main. ..» — это объявление главной процедуры. В качестве параметров в данную процедуру (функцию) передаются:

  • число аргументов командной строки — argc ;
  • указатель на массив аргументов командной строки — argv ;
  • указатель на массив переменных окружения — env .

Само тело программы помещается между символами фигурных скобок «<. >«. Фраза «тело программы» размещена между парой «/* . */». Это комментарий. Сама программа на С состоит из операторов. Операторы могут быть простые и составные. Простые операторы – это, например, оператор присваивания . Составной оператор — это блок. Блок представляет собой последовательность операторов , заключенную в фигурные скобки «<. >«. В конце простого оператора должен стоять символ «;». В нашем примере объявление (декларирование) переменных перед блоком тела программы — это последовательность простых операторов.

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

Стандартный поток вывода

Стандартный поток вывода в С ассоциируется с дескриптором STDOUT . Самым распространенным способом записи данных в этот поток является функция форматного вывода printf . Если скрипт должен что-то передать браузеру пользователя, то первое, что нужно сделать — это применить printf для формирования HTTP-заголовка:


Первый вызов printf формирует заголовок — определяет тип тела HTTP-отклика, а второй вызов формирует заглавие первого уровня в HTML-документе. В общем случае у функции printf три аргумента: printf(FILE,»format»,VARS_LIST); FILE — дескриптор файла, » format » — формат вывода данных, VARS_LIST — список переменных, чьи значения подлежат выводу. Если дескриптор файла опущен, то вывод направляется в поток стандартного вывода. Список переменных указывается в том случае, если в формате вывода есть шаблоны вывода для переменных из этого списка.

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

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

В данном случае переменная цикла i — это целая константа, поэтому в квадратных скобках указано [%d] . Второй аргумент списка переменных — указатель на массив символов (строка, содержащая значение аргумента командной строки ), поэтому после знака равенства («=») применен шаблон вывода массива символов %s .

Переменные окружения

Третий аргумент главной процедуры — указатель на массив переменных окружения, каждый элемент которого представляет собой строковую константу вида «имя- значение «. Неудобство работы с этим массивом заключается в том, что заранее не известно, сколько элементов он содержит. Список переменных окружения кончается в тот момент, когда при его переборе встречается указатель NULL . Пример такого перебора представлен ниже:

В данном случае перебор идет до тех пор, пока значение указателя больше 0. При этом переменные окружения выдаются в виде «имя: значение «. Для того, чтобы воспользоваться этими значениями, придется разбирать каждую строку, выделяя имя и значение переменной при помощи манипуляций с адресами внутри строки. Любые адресные операции — это потенциальные ошибки (хотя они и позволяют писать быстрые программы).

К счастью, в С есть функция getenv() . В качестве аргумента этой функции достаточно указать имя переменной окружения, и система вернет указатель на его значение . Например, необходимо знать, сколько символов нужно считать со стандартного ввода скрипта:

В этом примере при помощи последовательного применения getenv и atoi (ascii to integer ) из переменной окружения в переменную целого типа помещается значение переменной окружения — CONTENT_LENGTH . Последовательное применение функций здесь необходимо, т.к. значение переменной окружения — строка, а мы хотим использовать число, следовательно, строку символов следует не только получить, но еще и преобразовать в число.

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

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

Как сгенерировать SQL скрипт создания объектов и данных в Microsoft SQL Server?

Привет! Сегодня мы поговорим о том, как можно сгенерировать SQL скрипты создания объектов базы данных Microsoft SQL Server, включая сами данные, стандартными средствами SQL Server Management Studio (SSMS).

Что такое SQL скрипт объекта базы данных?

SQL скрипт объекта базы данных – это SQL инструкция, с помощью которой создается этот объект, сохраненная в текстовом файле.

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

Такой SQL скрипт можно открыть любым текстовым редактором, скопировать текст SQL запроса и выполнить, например, в среде SQL Server Management Studio, таким образом, создав объект базы данных, не разрабатывая соответствующие SQL инструкции самостоятельно.

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

Что могут содержать SQL скрипты?

SQL скрипты объектов базы данных могут содержать:

  • Инструкции создания таблиц (CREATE);
  • Заполнение таблиц (инструкции INSERT);
  • Определение представлений, функций, хранимых процедур, триггеров;
  • Определение ограничений и индексов;
  • Определение создания других объектов;
  • И другие SQL инструкции.

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

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

Или для того, чтобы передать эти SQL скрипты другому администратору, разработчику или заказчику, чтобы он создал подобные объекты на своем экземпляре SQL Server.

Таким образом, такие SQL скрипты необходимы для хранения копий SQL инструкций, с помощью которых создавались объекты базы данных.

Как создать SQL скрипт объекта базы данных в Microsoft SQL Server?

Так как SQL скрипт – это обычный текстовый файл, его можно создать вручную, например, когда Вы разрабатываете объект БД, Вы просто сохраняете SQL инструкцию в файл, и добавляете в него по мере необходимости другие SQL инструкции.

Однако также возможно автоматически сгенерировать SQL скрипты объектов базы данных специальными инструментами, например, в среде SQL Server Management Studio (SSMS). А как это делается, я сейчас и покажу.

Заметка! Если Вы хотите изучить язык T-SQL, рекомендую почитать книгу «Путь программиста T-SQL».

Создание SQL скрипта объекта базы данных Microsoft SQL Server

В качестве исходных данных у меня будет база данных TestDB и таблица Goods, SQL скрипт которой мне и нужно создать. При этом мне необходимо, чтобы скрипт включал не только определение инструкции CREATE, но и данные, которые содержит эта таблица.

В качестве инструмента я буду использовать SQL Server Management Studio.

Итак, давайте начнем.

Шаг 1 – Запускаем SSMS

Сначала запускаем среду SQL Server Management Studio любым удобным для Вас способом, иными словами, никаких особых манипуляций с открытием SSMS выполнять не требуется.

Шаг 2 – Запускаем задачу «Сформировать скрипты»

Далее в обозревателе объектов находим нужную нам базу данных, затем открываем контекстное меню правой кнопкой мыши, ищем пункт «Задачи», и выбираем задачу «Сформировать скрипты».

В итоге запустится мастер создания скриптов. В окне «Введение» можем сразу нажать «Далее».

Шаг 3 – Выбираем объекты для включения в SQL скрипт

После этого нам нужно выбрать объекты базы данных, которые необходимо включить в SQL скрипт. При этом нам доступно два варианта:

  • Создать скрипт для всей базы данных и всех ее объектов – этот вариант предполагает, что Вам нужен скрипт создания всех объектов в БД;
  • Выбрать отдельные объекты базы данных – в данном случае в скрипт включатся SQL инструкции только тех объектов, которые Вы укажете.

Так как мне нужно сохранить только одну таблицу, я выбираю второй вариант и отмечаю нужную таблицу, т.е. в моем случае Goods.

Шаг 4 – Задание параметров SQL скрипта

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

Доступно 3 способа:

  • Сохранить в файл – при этом мы можем сами указать нужный нам каталог для сохранения;
  • Сохранить в буфер обмена;
  • Сохранить в новое окно запросов.

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

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


Также Вы можете включить в скрипты инструкции DROP на случай, если Вам нужно пересоздать объекты.

После того как все параметры заданы, нажимаем «ОК», а после для продолжения кнопку «Далее».

Шаг 5 – Проверка параметров и запуск процесса создания скрипта

На данном шаге все проверяем и запускаем сам процесс формирования скрипта, т.е. нажимаем «Далее».

Шаг 6 – Завершение процесса и результат

Когда процесс будет завершен, программа сообщит Вам об этом, нажимаем «Готово».

В результате в каталоге, который Вы указали в параметрах формирования скрипта, появится SQL скрипт, а по факту обычный текстовый файл с расширением .sql.

Если его открыть, например, текстовым редактором, то можно посмотреть на все SQL инструкции. Они будут выглядеть примерно следующим образом.

Видео-инструкция

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Руководство по веб-разработке серверной части с помощью Node.js

Дата публикации: 2020-02-04

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

В этом посте приводится описание того, в чем заключается разработка серверной части веб с помощью Node.js, и краткое сравнение написания простого HTTP-сервера с использованием 3 различных фреймворков: Экспресс, Koa.js и Hapi.js.

Некоторые базовые принципы

Здесь я только хочу привести краткий обзор вещей для контекста. HTTP (Hypertext Transfer Protocol) — это протокол связи, используемый в компьютерных сетях. В Интернете их много, такие как SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), POP3 (Post Office Protocol 3) и так далее.

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

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

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

Серверы и клиенты

Термин «сервер» может немного сбивать с толку тех, кто плохо знаком с отраслью, поскольку он может относиться как к аппаратному обеспечению (физические компьютеры, на которых размещены все файлы и программное обеспечение, требуемое веб-сайтами), так и к программному обеспечению (программе, которая позволяет пользователям получать доступ к этим файлам в Интернете).

Сегодня мы поговорим о программной части. Но сначала несколько определений. URL обозначает Universal Resource Locator и состоит из 3 частей: протокола, сервера и запрашиваемого файла.

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

Сервер должен знать, как обрабатывать этот HTTP-запрос, чтобы получить правильный файл, а затем отправить его обратно браузеру, который его запросил. Наиболее популярное программное обеспечение веб-сервера, которое обрабатывает это Apache и NGINX.

Оба представляют собой полный пакет программ с открытым исходным кодом, которые включают в себя такие функции, как схемы аутентификации, перезапись URL-адресов, ведение журнала и проксирование, и это лишь некоторые из них. Apache и NGINX написаны на C. Технически, вы можете написать веб-сервер на любом языке. Python, Go, Ruby, этот список можно продолжаться довольно долго. Просто некоторые языки лучше делают определенные вещи, чем другие.

Введение в серверное программирование

Что? Какое еще серверное программирование? Что это за беда? И зачем она нам нужна?

Мы, вроде бы, научились создавать Web-страницы в среде Dreamweaver. Мы даже научились создавать с его помощью целые Web-сайты и публиковать их на Web-сервере. Мы изучили две разновидности дизайна страниц: фреймовый, когда сайты строятся на основе наборов фреймов, и табличный, когда содержимое страницы помещается в большую сложную таблицу. Мы познакомились с таблицами стилей, метатегами и серверными директивами. И, наконец, узнали о Web-программировании и Web-сценариях, позволяющих добавить «жизни» нашим статичным страничкам. Что же еще надо для счастья?

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

Так давайте же сделаем следующий шаг — перейдем от страниц, хранящихся в файлах на сервере, к страницам, генерируемым специальными программами. Как раз написанием таких программ и занимается серверное программирование.

Но давайте по порядку. И начнем мы с того, что выясним, зачем нужны эти серверные программы.

Что такое серверное программирование

Действительно, что это такое и с чем его едят?

Зачем нужны серверные программы

Вы когда-нибудь посещали интернет-магазин? Например, популярнейший «Озон» (http://www.ozon.ru). Помните, как там выполняется заказ товара?

Если не помните или вообще не знаете, что такое интернет-магазин, давайте вспомним (или узнаем).

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

Что происходит при этом? Как обрабатываются введенные вами данные? Неужели самим Web-обозревателем?

Отнюдь. Эти данные обрабатываются на Web-сервере.

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

Как это происходит на деле? Сейчас мы это выясним. И первым делом ответим на вопрос.

Как Web-сервер обрабатывает данные пользователя

Итак, каким же образом программа Web-сервера обрабатывает данные, отправленные ей пользователем?

Да никак. Web-сервер не приспособлен их обрабатывать. Его задача: прием от Web-обозревателя запроса на файлы (Web-страницы, таблицы стилей, графические изображения, фильмы, звуки, архивы, исполняемые файлы и т. п.), поиск этих самых файлов на жестких дисках серверного компьютера и отправка найденных файлов назад Web-обозревателю. Это его основная задача. Конечно, некоторые особо мощные серверы могут выполнять дополнительные действия над отправляемыми файлами перед собственно их отправкой (в частности, выполнять серверные директивы). Есть и программы-«многостаночники», выполняющие функции не только Web-сервера, но и сервера FTP, почты, новостей UseNet и бог знает чего еще. Но основная функция: простая выдача файлов по требованиям клиентов -и не более того.

Секрет в том, что данные посетителя обрабатываются не самим Web-сервером. Для этого применяются специальные программы, работающие вместе с Web-сервером на том же серверном компьютере. Они называются серверными программами, не имеют интерфейса пользователя и «общаются» только с Web-сервером, принимают от него введенные пользователем данные и возвращают ему результат. Этим они коренным образом отличаются от клиентских программ, работающих непосредственно с пользователем. (К клиентским программам относится, в частности, ваш любимый Web-обозреватель.)

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

Вот тут-то и начинается самое интересное. Дело в том, что результат, возвращаемый серверной программой Web-серверу, — это не что иное, как обычный HTML-код! Фактически серверная программа возвращает готовую Web-страницу, сформированную на основе данных, введенных посетителем. Такая страница называется динамической, в отличие от статических страниц, написанных Web-дизайнером и сохраненных в файлах на дисках серверного компьютера. А уж эту динамическую страницу Web-сервер и направляет клиенту в качестве ответа на введенные данные.

Серверные программы делятся на следующие четыре вида.

  1. Исполняемые программы, работающие через интерфейс CGI (Common Gateway Interface — общий интерфейс обмена), так называемые CGI-npoграммы. Эта разновидность серверных программ — самая старая, однако отнюдь не устаревшая.
  2. Расширения Web-сервера (приложения формата ISAPI, NSAPI, модули расширения Apache и т. п.). Новый способ, позволяющий встраивать серверные программы в сам Web-сервер, делая их его составными частями. Впервые предложен фирмой Microsoft для их сервера Microsoft Internet Information Server (интерфейс ISAPI) и разработчиками популярного бесплатного Web-сервера Apache.
  3. Активные серверные страницы (ASP, JSP и др.). Фактически это обычные статические Web-страницы, сохраненные в файлах, Которые, кроме обычного HTML-кода, включают в себя команды, обрабатываемые либо самим Web-сервером, либо его расширением. Также новый способ, впервые предложенный Microsoft для того же Internet Information Server.
  4. Серверные сценарии, написанные на интерпретируемом языке (Perl, Python, VBScript, JavaScript и др.). Обычные сценарии, работающие через интерфейс CGI или ISAPI на стороне сервера.

Теперь рассмотрим все это разнообразие подробнее.

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

К достоинствам CGI-программ можно отнести легкость создания (многие среды разработки программ поддерживают создание таких приложений, в частности популярнейший Borland Delphi, начиная с версии 3) и простоту отладки. Также, поскольку CGI-приложения представляют собой независимые программы, они выполняются отдельно от Web-сервера (как говорят программисты и системные администраторы, выполняются в другом адресном пространстве). Это значит, что при сбое в CGI-программе завершается только она — сам Web-сервер остается «на плаву». А недостаток у CGI-программ всего один: большой расход системных ресурсов, поскольку для обработки каждого набора данных запускается отдельная копия серверной программы. И если Web-серверу поступит слишком много запросов на обработку данных, серверный компьютер может и зависнуть.

Расширения Web-сервера — более новая разновидность серверных программ. Они представляют собой обычные библиотеки DLL, в которых реализована вся логика серверной программы. Такие библиотеки как бы встраиваются в программу Web-сервера и работают как ее неотъемлемая часть. Поскольку библиотеки DLL работают только в среде Windows, для того чтобы создавать расширения в иных операционных системах, были придуманы и другие форматы. В частности, модули расширения сервера Apache не являются библиотеками DLL,

Именно в виде библиотек DLL создаются расширения Web-серверов Internet Information Server фирмы Microsoft и Netscape Web Server фирмы Netscape. В первом случае расширения имеют формат ISAPI (Internet Server Application Programming Interface — интерфейс программирования приложений интернет-сервера), а во втором — NSAPI (Netscape Server Application Programming Interface — интерфейс программирования приложений сервер^ Netscape). Формат модулей расширения Apache так и называется — модули Apache.

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

Как CGI-программы. Поскольку они работают как часть Web-сервера, любая ошибка в расширении приведет к зависанию сервера.

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

Как уже говорилось, активные серверные страницы — это обычные Web-страницы, включающие в себя особые серверные сценарии, выполняемые самим Web-сервером или специальной серверной программой (CGI-приложением или расширением Web-сервера). В частности, ASP (Active Server Pages — активные серверные страницы), поддерживаемые Microsoft Internet Information Server, и JSP (Java Server Pages — серверные страницы, написанные на JavaScript), поддерживаемые рядом других Web-серверов, работают именно таким образом. Серверные страницы ASP пишутся на языках JavaScript и VBScript, a JSP — только на JavaScript.

Достоинства активных серверных страниц вы уже знаете: легкость и быстрота написания и простота отладки. Кроме того, поскольку активные серверные страницы — это обычные Web-страницы с «вкраплениями» программного кода, их написание легко освоят все, кто знаком с HTML. Недостаток: относительная медлительность и повышенные требования к системным ресурсам.

Серверные сценарии подобны активным серверным страницам тем, что являются интерпретируемыми, однако представляют собой «чистый» программный код, без HTML-»примесей». Интерпретатор практически всегда представляет собой CGI-программу, однако ничто не мешает разработать его в виде расширения Web-сервера. Сценарии обычно пишутся на языке программирования Perl, специально предназначенном для обработки текста; также используются языки Python, JavaScript, VBScript и даже (как говорят) язык командных файлов MS-DOS. Фактически писать сценарии можно на любом языке программирования, для которого есть интерпретатор.

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

В табл. 15.1 приведены расширения файлов серверных программ.

Таблица 15.1. Расширения файлов серверных программ

Илон Маск рекомендует:  Что такое код jdmonthname
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
JavaScript Java