Как работает веб сервер. Нетривиальные случаи работы с серверами. Доменные имена и их покупка

Грамотная клиент-серверная архитектура: как правильно проектировать и разрабатывать 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». Самый простой ответ сервера, не содержащий никаких данных, будет выглядеть так:

POST /api/v1/articles/22/publish { "success": true }

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

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

GET /api/v1/user { "success": false, "error": { "code" : 401, "message" : "Authorization failed" } }

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

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

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

GET /api/v1/user { "success": true, "data": { "id" : 125, "email" : "[email protected]", "name" : "John", "surname" : "Smith", } }

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

PUT /api/v1/user { "success": false, "error": { "code" : 422, "message" : "Validation failed" } "data": { "email" : "Email could not be blank.", } }

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

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

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

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

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

GET /api/v1/articles Response: { "success": true, "data": [ { "id" : 1, "title" : "Interesting thing", }, { "id" : 2, "title" : "Boring text", } ], "pagination": { "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, } }

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

Как уже упоминалось выше, не все запросы к 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 .

GET /api/v1/news?page=1

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

GET /api/v1/news?perPage=100

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

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

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

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

GET /api/v1/products?sortBy=name.desc,price.asc

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

GET /api/v1/products? sortBy=name& sortBy=desc& sortBy=price& sortBy=asc

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

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

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

GET /api/v1/articles?authorId=25

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

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

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

GET /api/v1/products?price=500&price=1000

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

GET /api/v1/products?status=1&status=2

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

GET /api/v1/users?name=John GET /api/v1/products?code=123

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

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

GET /api/v1/products?filters=recommended

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

GET /api/v1/products?filters=kidds

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

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

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

Статья написана на основе опыта работы с серверами:

Apache, Lighttpd, Nginx (на C)
Tomcat, Jetty (на Java)
Twisted (Python)
Erlang OTP (язык Erlang)
и операционными системами Linux, FreeBSD

Тем не менее, принципы достаточно общие, поэтому должны распространяться в каком-то виде на OS Windows, Solaris, и на большое количество других веб-серверов.

Цель веб-сервера

Цель веб-сервера проста - обслуживать одновременно большое количество клиентов, максимально эффективно используя hardware. Как это сделать - в этом основная заморочка и предмет статьи;)

Работа с соединениями

С чего начинается обработка запроса? Очевидно - с приема соединения от пользователя.

Для этого в разных OS используются разные системные вызовы. Наиболее известный и медленный на большом количестве соединений - select . Более эффективные - poll, kpoll, epoll.

Современные веб-серверы постепенно отказываются от select.

Оптимизации ОС

Еще до приема соединения возможны оптимизации на уровне ядра ОС. Например, ядро ОС, получив соединение, может не беспокоить веб-сервер, пока не произошло одно из событий.

пока не пришли данные (dataready)
пока не пришел целиком HTTP-запрос (httpready)

На момент написания статьи оба способа поддерживаются во FreeBSD (ACCEPT_FILTER_HTTP, ACCEPT_FITER_DATA), и только первый - в Linux (TCP_DEFER_ACCEPT).

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

Соединение принято

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

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

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

В зависимости от реализации - процесс-помощник ("worker") может пересылать результат обратно серверу целиком (для последующей отдачи клиенту), может передавать серверу только дескриптор результата (без копирования), или может отдавать результат клиенту сам.

Основные стратегии работы с worker"ами

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

Тип worker"а

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

Процесс

Различные worker"ы могут быть процессами. В этом случае они не взаимодействуют между собой, и данные различных worker"а полностью независимы друг от друга.

Поток

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

Адресное пространство

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

Внутри сервера

При работе внутри сервера - worker имеет доступ к данным сервера. Он может поменять любые структуры и делать разные гадости, особенно если написан с ошибками.

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

Снаружи сервера

Worker может быть запущен вообще независимо от сервера и принимать данные на обработку по специальному протоколу (например FastCGI).

Конечно, этот вариант - самый безопасный для сервера. Но требует дополнительной работы по пересылке запроса - результата между сервером и worker"ом.

Рождение worker"ов

Чтобы обрабатывать много соединений одновременно - нужно иметь достаточное количество рабочих.

Основных стратегий - две.

Статика

Количество рабочих может быть жестко фиксированно. Например, 20 рабочих процессов всего. Если же все рабочие заняты и приходит 21й запрос - сервер выдает код Temporary Unavailable - "временно недоступен".

Динамика

Для более гибкого управления ресурсами - рабочие могут порождаться динамически, в зависимости от загрузки. Алгоритм порождения рабочих может быть параметризован, например (Apache pre-fork), так:

Минимальное количество свободных рабочих = 5
Максимальное количество свободных рабочих = 20
Всего рабочих не более = 30
Начальное количество рабочих = 10

Чистка между запросами

Рабочие могут либо заново инициализовать себя между запросами, либо - просто обрабатывать запросы один за другим.

Чистый

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

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

Персистентный

Никакой очистки состояния. В результате - экономия ресурсов.

Разбор типичных конфигураций

Посмотрим, как эти комбинации работают на примере различных серверов.

Apache (pre-fork MPM) + mod_php

Для обработки динамических запросов используется модуль php, работающий в контексте сервера.

Процесс
Внутри сервера
Динамика
Чистый

Apache (worker MPM) + mod_php

Для обработки динамических запросов используется модуль php, работающий в контексте сервера.

При этом, так как php работает в адресном пространстве сервера, разделяемые потоками данные периодически портятся, поэтому связка нестабильна и не рекомендована. Это происходит из-за ошибок в mod_php, который включает в себя ядро PHP и различные php-модули.

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

Поток
Внутри сервера
Динамика
Чистый

Apache (event mpm) + mod_php

Event MPM - это стратегия работы с worker"ами, которую использует только Apache. Все - точно так же, как с обычными потоками, но с небольшим дополнением для обработки Keep-Alive

Установка Keep-Alive служит для того, чтобы клиент мог прислать много запросов в одном соединении. Например, получить веб-страницу и 20 картинок. Обычно, worker заканчивает обработку запроса - и ждет какое-то время (keep-alive time), не последуют ли в этом соединении дополнительные запросы. То есть, просто висит в памяти.

Event MPM создает дополнительный поток, который берет на себя ожидание всех Keep-Alive запросов, освобождая рабочего для других полезных дел. В результате, общее количество worker"ов значительно сокращается, т.к никто теперь не ждет клиентов, а все работают.

Поток
Внутри сервера
Динамика
Чистый

Apache + mod_perl

Особенность связки Apache с mod_perl - в возможности вызывать Perl-процедуры по ходу обработки запроса апачем.

Благодаря тому, что mod_perl работает в одном адресном пространстве с сервером - он может регистрировать свои процедуры через Apache hooks, на разных стадиях работы сервера.

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

Следующий пример описывает rewrite с /example на /passed, но на перле.

# в конфиге апача при включенном mod_perl PerlModule MyPackage::Example PerlTransHandler MyPackage::Example # в файле MyPackage/Example.pm package MyPackage::Example use Apache::Constants qw(DECLINED); use strict; sub handler { my $r = shift; $r->uri("/passed") if $r->uri == "/example" return DECLINED; } 1;

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

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

Процесс/поток - зависит от MPM
Внутри сервера
Динамика
Персистентный

Twisted

Этот асинхронный сервер написан на Python. Его особенность - в том, что программист веб-приложения сам создает дополнительных рабочих и дает им задания. # пример кода на сервере twisted # долгая функция, обработка запроса def do_something_big(data): .... # в процессе обработки запроса d = deferToThread (do_something_big, "параметры") # привязать каллбеки на результат do_something_big d.addCallback(handleOK) # .. и на ошибку при выполнении do_something_big d.addErrback(handleError)

Здесь программист, получив запрос, использует вызов deferToThread для создания отдельного потока, которому поручено выполнить функцию do_something_big. При успешном окончании do_something_big, будет выполнена функция handleOK, при ошибке - handleError.

А текущий поток в это время продолжит обычную обработку соединений.

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

Поток
Внутри сервера
Динамика
Персистентный

Tomcat, Servlets

Сервлеты - классический пример поточных веб-приложений. Единый Java-код приложения запускается во множестве потоков. Синхронизация обязательна и должна выполняться программистом.

Поток
Внутри сервера
Динамика
Персистентный

FastCGI

FastCGI - интерфейс общения web-сервера с внешними worker"ами, которые обычно запущены как процессы. Сервер в специальном (не HTTP) формате передает переменные окружения, заголовки и тело запроса, а worker - возвращает ответ.

Есть два способа порождения таких worker"ов.

Интегрированный с сервером
Отдельный от сервера

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

Во втором случае - для порождения рабочих процессов используется отдельный "spawner", второй, дополнительный сервер, который умеет общаться только по FastCGI-протоколу и управлять рабочими. Обычно spawner порождает рабочих в виде процессов, а не потоков. Динамика/Статика - определяется настройками spawner"а, а Чистый/Персистентный - характеристиками рабочего процесса.

Пути работы с FastCGI

С FastCGI можно работать двумя путями. Первый способ - самый простой, его использует Apache.

получить запрос -> отдать на обработку в FastCGI -> подождать ответа -> отдать ответ клиенту.

Второй способ используют сервера типа lighttpd/nginx/litespeed/и т.п.

получить запрос -> отдать на обработку в FastCGI -> обработать других клиентов -> отдать ответ клиенту, когда придет.

Отмеченное отличие позволяет Lighttpd + fastcgi работать эффективнее, чем это делает Apache, т.к пока процесс Apache ждет - Lighttpd успевает обслужить другие соединения.

Режимы работы FastCGI

У FastCGI есть два режима работы.

Responder - обычный режим, когда FastCGI принимает запрос и переменные, и возвращает ответ
Authorizer - режим, когда FastCGI в качестве ответа разрешает или запрещает доступ. Удобно для контроля за закрытыми статическими файлами

Оба режима поддерживаются не во всех серверах. Например, в сервере Lighttpd - поддерживаются оба.

FastCGI PHP vs PERL

PHP-интерпретатор каждый раз очищает себя перед обработкой скрипта, а Perl - просто обрабатывает запросы один за другим в цикле вида:

Подключить модули; while (пришел запрос) { обработать его; print answer; } Поэтому Perl-FastCGI гораздо эффективнее там, где большУю часть времени выполнения занимают include вспомогательных модулей.

Резюме

В статье рассмотрена общая структура обработки запросов и виды worker"ов. Кроме того, заглянули в Apache Event MPM и способы работы с FastCGI, посмотрели сервлеты и Twisted.

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

Ниже мы приводим адаптированный перевод статьи The non-techie’s guide to servers Кеннена Чандрасегарана (Kannan Chandrasegaran), разработчика из компании Panopto. Просим обратить внимание, что статья рассчитана на новичков, которые мало знакомы с понятием серверной части приложения и серверов.

Из жизни офиса

Сложно быть «не-технарём» в ИТ-компании, уж поверьте! Маркетологи, менеджеры по продажам, бухгалтеры - не суть важно - время от времени они сталкиваются со своими технически подкованными коллегами. Это могут быть программисты или системные администраторы.... В любом случае, "не-технари" чувствуют себя так, будто им ампутировали важную часть мозга. Или они высадились на неизвестную планету с разумной негуманоидной жизнью. Или…

Иногда, конечно, всё заканчивается благополучно. Вот, например, девушка-« », идёт по коридору. Ничто не предвещает беды: она направляется налево, вы – направо, и как можно быстрее… Нет, в этот раз не пронесло. Вы уже сидите с ней за столом, и пытаясь побороть неловкое молчание, спрашиваете: «А...чем именно ты занимаешься?». Она начинает рассказывать что-то, но вы не сразу врубаетесь, о чём она. Вроде бы и слова знакомые: пользовательский интерфейс, приложения, и - точно, Facebook - это сайт. Ага, там есть кнопочки, меню… Вы кое-как разобрались в хитросплетениях её работы, киваете ей на прощание и ваши пути расходятся в коридорах большого офиса.

Но рано или поздно вам не так повезёт: вы встретите инженера по серверам. Или бек-энд разработчика. Не зная в какие дебри сейчас попадёте, вы наивно задаёте тот же вопрос и... получаете абракадабру в ответ. Слышите уйму иностранных слов, а в голове пробегают мысли: «Прилично ли спросить, что такое API?», «Мы всё время используем «бэдэ» (DataBase), правда, что ли?», «Кто такой, чёрт побери, этот Джейсон (JSON)??». Ваш знакомый инженер пытается рассказать вам о серверах, но не понимает, насколько вам сложно понять его наполненную профессиональными терминами речь. Вероятно, вы уже слышали слово "сервер" раньше, но его употребляют в настолько разных контекстах, что осознать его значение крайне сложно. Что ж попробуем разобраться с этим термином.

Вниз по кроличьей норе

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

Говоря о фронт-энде и бек-энде, программисты обычно подразумевают разделение пользовательской части приложения от программной логики. Итак, фронт-энд (front-end) - это интерфейсная часть приложения, а бек-энд (back-end) - его серверная часть.

Серверы

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

Хранилища или системы хранения данных

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

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

Это позволяет ответить на многие вопросы. Например:

Сколько пользователей лайкнули этот ресторан?
Какие рестораны нравятся этому пользователю?
Блюда какой кухни нравятся сразу нескольким пользователям?

Информация и связи между данными хранятся в базе данных (БД). Существует множество видов баз данных, но все они:

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

Существует много видов баз данных, каждая из которых имеет свои преимущества и недостатки. Если вы слышите такие термины как SQL, MySQL, MongoDB, CouchDB, Redis, то знайте - речь идет о базах данных.

Взаимодействие

Ключевая задача сервера - взаимодействие с приложением и другими серверами.

Многие задачи приложения требуют взаимодействия с сервером. Например, если пользователь что-то ищет, поисковый запрос посылается на сервер и оттуда приходит результат. Если пользователь шлет сообщение другому пользователю, оно сначала приходит на сервер. А затем оттуда отправляется на приложение другого пользователя, чаще всего в виде отправленного уведомления. Интерфейсы, которые предоставляет сервер для того, чтобы приложения могли с ним взаимодействовать, обычно называются API . Ну а какие-то функции интерфейса можно сопоставить с конечными точками (endpoints), например, с поиском или авторизацией на сайте. Непосвященным такое взаимодействие может показаться странным. Двумя наиболее распространенными форматами взаимодействия являются JSON и XML.

XML слева, JSON справа На первый взгляд форматы выглядят трудночитаемыми. Важно понимать, что сервер - это просто компьютер, как ваш ноутбук или смартфон. Приложение на вашем телефоне принимает пользовательский ввод в голосовом или текстовом виде, с помощью распознавания голоса или касания к экрану. Приложение обрабатывает эту информацию, а затем дает ответ в виде изображения на экране. Смартфон -компьютер, который взаимодействует с человеком, поэтому ввод и вывод предоставляются в удобной для человека форме. Сервер - вычислительная машина, которая взаимодействует только с другими компьютерами. Человек воспринимает информацию благодаря таким вещам как: размер шрифта, цвет текста и форматирование. Но это ничего не значит для компьютера.

Серверное приложение

Если вы хотите создать приложение, которое будет работать на вашем телефоне, вам также понадобится приложение, которое будет работать на сервере. Серверные приложения создаются с помощью серверных языков программирования и фреймворков, популярными вариантами которых являются Java , Ruby on Rails , Node.js , PHP , ASP.NET .

Можно сказать, что API - это «двери» вашего сервера и приложение знает, что в них надо стучать. База данных хранит всю вашу информацию. А серверное приложение – это «мозг», который связывает все вместе. Оно получает и отвечает на запросы, которые поступают ему через API, добавляет и извлекает информацию из базы данных, и принимает решения. Например, когда пользовательское приложение отправляет информацию для входа, запрос поступает через API, правильная информация для входа хранится в базе данных. Задачей серверного приложения сравнить их и соответственно ответить приложению, используя API.

Аппаратное обеспечение

Когда вы слышите слово «сервер», скорее всего, вы представляете такую картинку: шкафы с мерцающими лампочками в закрытой комнате. Вероятно, для полноты картины, не хватает только Тома Круза, который спустится с потолка и что-нибудь крадёт. Многие большие компании владеют собственными серверами и целыми центрами обработки данных (те самые огромные комнаты с мерцающими шкафами). У Facebook и Google сотни серверов по всему миру. Когда вы руководите огромным сервисом с миллионами пользователей, содержание собственных серверов может быть значительно дешевле и это обеспечит более высокую производительность. Вместо того чтобы содержать свои собственные сервера многие разработчики используют облачные сервисы. Такие сервисы как Amazon Web Services, Azure и Digital Ocean предлагают возможность использования «виртуальных серверов». Эти сервисы владеют и обслуживают аппаратное обеспечение, а разработчик просто загружает на него серверное приложение. Некоторые провайдеры услуг предоставляют бекэнд как сервис, позволяя вам иметь простой бэкенд без необходимости писать серверное приложение самостоятельно.

Всем ли приложениям нужен бэкенд?

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

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

Контроль ошибок при написании кода

Мониторинг сайта в поисковых системах

Создание эскиза будущего проекта

Онлайн-сервисы для решения задач дизайна и веб-разработки

Работа с сервером

Установка сервера Apache

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

Установка и настройка PHP

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

Установка и настройка сервера баз данных (MySQL)

Если Вы собираетесь делать сайты с использованием баз данных (а так скорее всего и будет), то для полноценной работы помимо Apache и PHP понадобится установить и настроить сервер баз данных - в нашем случае это MySQL. Об этом и будет идти речь в данной статье.

Установка и настройка phpMyAdmin

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

Как правило, у рядового пользователя такие понятия, как «веб-сервер» или «хостинг», ассоциируются с чем-то абсолютно непонятным. Между тем, ничего сложного в этом вопросе нет. Попытаемся объяснить, что собой представляет web server, зачем он нужен и как работает, особо не вдаваясь в технические подробности, а, так сказать, на пальцах. Отдельно остановимся на вопросе о том, как создать и настроить такой сервер на домашнем компьютерном терминале или ноутбуке.

Что такое веб-сервер?

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

Но это абсолютно не значит, что в домашних условиях нельзя создать собственную конфигурацию. Поскольку у нас более распространенными являются операционные системы Windows, вопросы о том, как создать веб-сервер на Ubuntu (Linux), рассматриваться не будут.

Для чего нужны web-серверы?

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

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

Как это все работает?

Все пользователи привыкли, что для входа на какой-то ресурс в интернете (веб-страницу), на котором располагается информация определенного типа, в адресной строке просто вводится префикс www (или http) и последующее имя. Но никто не задумывается о том, каким образом web server понимает запрос и выдает результат.

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

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

Самые популярные web-серверы

Из всего серверного программного обеспечения, как считается, самыми распространенными являются Apache и Microsoft IIS. Первый является более популярным и в большей степени используется в UNIX-подобных системах, хотя и может устанавливаться в среду Windows. Кроме того, сервер Apache является абсолютно бесплатным программрным обеспечением и совместим практически со всеми известными операционными системами. Однако, как отмечается, предназначено это ПО в основном для профессиональных программистов и разработчиков.

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

Тем не менее, если исходить из официальной статистики, программное обеспечение Apache использует порядка 60% всех существующих серверов, поэтому вопрос установки и настройки начальной конфигурации рассмотрим именно на его примере.

Веб-сервер на домашнем компьютере: установка

Для инсталляции потребуется скачать специальный серверный пакет, сокращенно обозначаемый как WAMP, в который входит три основных компонента:

Apache - программная оболочка сервера, которая может работать самостоятельно, но только в случае отсутствия на размещаемых страницах динамического контента.
PHP - язык программирования, используемый надстройками для управления серверами с динамическим содержимым вроде WordPress, Joomla, Drupal.
MySQL - унифицированная система управления базами данных, используемая, опять же, при создании сайтов с динамическим контентом.

Инсталляцию можно произвести из пакета WampServer. Для этого достаточно следовать указаниям «Мастера», который на одной из стадий предложит выбрать интернет-браузер, который будет использоваться по умолчанию.

Для этого нужно будет перейти в папку с исполняемым файлом браузера (если это не Internet Explorer, обычно она располагается в директории Program Files). Попутно сам браузер следует добавить в список исключений брэндмауэра Windows. На финишной стадии ставится галочка напротив пункта немедленного запуска, после чего в системном трее появится соответствующий значок, на который нужно нажать и изменю выбрать запуск локального хоста (localhost).

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

Пример настройки и тестирования сервера

Настройка веб-сервера несколько сложнее. Сначала в меню системного трея выбирается переход в папку WWW (место хранения надстроек или файлов HTML). После этого прописать следующий текст в «Блокноте»:

WAMP тест!

Привет!

"; ?>

Можете просто скопировать текст в «Блокнот» и сохранить файл под именем index.php в той самой папке WWW (хотя можно обойтись и без того, поскольку этот шаг применяется исключительно для проверки локального хоста). Вместо приветствия можете вставить любой другой текст или фразу.

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

Чтобы открыть доступ, нужно изменить файл httpd.conf, прописав в разделе, который начинается с следующие строки:

Order Allow,Deny

Вместо послесловия

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