CC BY
98ТЕХНИЧЕСКИЕ НАУКИ
ПОСТРОЕНИЕ КЛИЕНТ-СЕРВЕРНЫХ ПРИЛОЖЕНИЙ Танатканова А.К.1, Жамбаева А.К.2
'Танатканова Асель Кайратовна — студент, специальность: информатика;
2Жамбаева Анар Куанышбековна — старший преподаватель, кафедра информатики, Костанайский государственный университет им. А. Байтурсынова, г. Костанай, Республика Казахстан
Аннотация: в статье раскрываются понятия «клиент» и «сервер», анализируется способ общения между сервером и клиентом, философия REST.
Ключевые слова: архитектура, клиент, сервер, REST, GET, POST, объект, JSON.
В архитектуре клиент-сервер сервер исполняет роль обработчика клиентских запросов. Сервер приложения обрабатывающие клиентский запрос. В рамках обычной клиент-серверной системы клиент обращается к данным, находящимся на сервере. Сервер в данном случае выступает и как сервер данных, и как обработчик запросов.
Взаимоотношения между клиентом и сервером осуществляются посредством использования протокола передачи данных. Клиент посылает свой запрос, используя протокол, понятный серверу. В данный момент не важно, какой именно тип клиента отправляет запрос и по какому протоколу, важно, чтобы и сервер, и клиент одновременно и совместно использовали один и тот же протокол передачи. [1, 18]
REST (Representational state transfer) изначально был задуман как простой и однозначный интерфейс для управления данными, предполагавший всего несколько базовых операций с непосредственным сетевым хранилищем (сервером): извлечение данных (GET), сохранение (POST), изменение (PUT/PATCH) и удаление (DELETE). Разумеется, этот перечень всегда сопровождался такими опциями, как обработка ошибок в запросе (корректно ли составлен запрос), разграничение доступа к данным (вдруг этого вам знать не следует) и валидация входящих данных (вдруг вы написали ерунду), в общем, всеми возможными проверками, которые сервер выполняет перед тем, как выполнить желание клиента. [2]
Помимо этого REST имеет ряд архитектурных принципов, перечень которых можно найти в любой другой статье о REST. Пробежимся по ним кратко, чтобы они были под рукой, и не пришлось никуда уходить:
Независимость сервера от клиента - серверы и клиенты могут быть мгновенно заменены другими независимо друг от друга, так как интерфейс между ними не меняется. Сервер не хранит состояний клиента.
Уникальность адресов ресурсов - каждая единица данных (любой степени вложенности) имеет свой собственный уникальный URL, который, по сути, целиком является однозначным идентификатором ресурса.
Независимость формата хранения данных от формата их передачи - сервер может поддерживать несколько различных форматов для передачи одних и тех же данных (JSON, XML и т.д.), но хранит данные в своем внутреннем формате, независимо от поддерживаемых.
Присутствие в ответе всех необходимых метаданных - помимо самих данных сервер должен возвращать детали обработки запроса, например, сообщения об ошибках, различные свойства ресурса, необходимые для дальнейшей работы с ним, например, общее число записей в коллекции для правильного отображения постраничной навигации. Мы еще пройдемся по разновидностям ресурсов.
Ключевым типом данных в общении между клиентом и сервером выступает объект. По сути, объект - это перечень свойств и соответствующих им значений. Мы можем отправить объект на сервер в запросе и получить в результат запроса в виде объекта. При этом объект не обязательно будет реальной сущностью, хранящейся в базе данных, по крайней мере, в том виде, в котором он отправлен или получен. Например, учетные данные для авторизации передаются в виде объекта, но не являются самостоятельной сущностью. Даже хранимые в БД объекты склонны обрастать дополнительными свойствами внутрисистемного характера, например, датами создания и редактирования, различными системными метками и флагами. Свойства объектов могут быть как собственными скалярными значениями, так и содержать связанные объекты и коллекции объектов, которые не являются частью объекта. Часть свойств объектов может быть редактируемой, часть
системной, доступной только для чтения, а часть может носить статистический характер и вычисляться на лету (например, количество лайков). Некоторые свойства объекта могут быть скрыты, в зависимости от прав пользователя.
Самым удобным и функциональным, по мнению многих, форматом обмена данными является JSON, но никто не запрещает использовать XML, YAML или любой другой формат, позволяющий хранить сериализованные объекты без потери типа данных. При желании можно сделать в API поддержку нескольких форматов ввода/вывода. Достаточно задействовать HTTP заголовок запроса для указания желаемого формата ответа Accept и Content-Type для указания формата переданных в запросе данных. Другим популярным способом является добавление расширения к URL ресурса, например, GET /users.xml , но такой способ кажется менее гибким и красивым, хотя бы потому, что утяжеляет URL и верен скорее для GET-запросов, нежели для всех возможных операций.
Список литературы
1. Мухамедзянов Р.Р. Java. Серверные приложения // Солон-Р, 2002.
2. Как правильно проектировать и разрабатывать Web API. [Электронный ресурс]. Режим доступа: https://tproger.ru/articles/web-api/ (дата обращения: 30.05.2019).
3. Орфали Р., Харки Д. Java и CORBA в приложениях клиент сервер. М.: ЛОРИ, 2000.
4. Усенков Д. Уроки Web-мастера / Д. Усенков. М.: Лаборатория Базовых Знаний, 2001.
ЗАВИСИМОСТЬ ДЕБИТА ГОРИЗОНТАЛЬНЫХ СКВАЖИН ОТ ДЛИНЫ ГОРИЗОНТАЛЬНОГО УЧАСТКА НА СТЕПНОМ МЕСТОРОЖДЕНИИ
Жмаев Н.Ю.
Жмаев Николай Юрьевич — магистрант, кафедра разработки и эксплуатации нефтяных и газовых месторождений, Тюменский индустриальный университет, г. Тюмень
Аннотация: данная статья является частью магистерской диссертации на тему «Анализ методов повышения нефтеотдачи на Степном месторождении».
Цель данной статьи произвести расчет влияния длины горизонтального участка на дебит скважин и доказать оптимальную длину горизонтального участка для условий Степного месторождения. Произведен расчет начальных, входных дебитов горизонтальных скважин с различной длиной горизонтального участка в условиях Степного месторождения. Проведено сравнение расчётных показателей, прирост дебита от увеличения длины горизонтального участка.
Ключевые слова: Степное нефтяное месторождение, горизонтальный участок, расчет дебита скважины.
УДК 622
В продолжение предыдущих статей продолжим анализ повышения нефтеотдачи на Степном месторождении [8, 9].
Для анализа полученных дебитов сконцентрируем внимание на наиболее перспективном эксплуатационном объекте. Нефтяная залежь нижнего пласта пашийского горизонта разрабатывается с августа 2006 года. За весь срок эксплуатации залежь нижнего пласта пашийского горизонта дренировалась двумя скважинами (№1 и 6).
На его долю в общем объеме запасов нефти категории В1 по месторождению приходится 3167 тыс.т или 61,5% начальных геологических запасов и 792 тыс.т или 57,6 % начальных извлекаемых запасов.
Проследим зависимость дебита горизонтальной скважины с использованием формул Грачева, Телкова; Фолефака-Арчера; Борисова; S.D. Joshi; Giger [1-7]. При разной длине горизонтального участка. Исходные данные взяты из таблицы № 1.
Таблица 1. Исходные данные для расчета
X* К(мД) дР(МПа) ц (Па*с) L (м) h0 (м) Rc (м)
Пашинский ниж. екв №1 5 0,0493 4 0,00038 100 5 0,11
Пашинский ниж. екв N°6 5 0,0493 4 0,00038 100 6 0,11
