По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Как и множество других инструментов для управления и автоматизации на рынке программного обеспечения, Ansible был изначально open – source проектом (с открытым исходным кодом), который предназначался для автоматизации настройки и деплоймента (развертывания) ПО в сетевых контурах компаний. Чего скрывать, продукт «стрельнул» - когда компания AnsibleWorks это поняла, начала активную монетизацию через коммерческую поддержку продукта для корпоративных заказчиков.
/p>
В настоящее время их продуктовая линейка состоит из двух направлений - Ansible и Ansible Tower, причем последний обладает полноценным интерфейсом управления (UI) и возможностью реализации дашбордов.
Ansible - новые ребята в DevOps направлении, по сравнению, например, с Chef или Puppet, но успели круто зарекомендовать себя в сообществе профессионалов за простоту и скоуп возможностей. Его playbooks понятны и легко читаемы, даже без особых знаний.
Так к чему это все? В «правильных руках», где присутствует полное понимание плюсов и минусов продукта Ansible может работать еще круче :) Поэтому, хотим рассказать про 5 лучших и 5 худших свойств Ansible.
Playbooks в Ansible это файл в формате YAML, который содержит последовательность состояния ресурсов системы, задач, которые позволяет запустить то или состояние сервера.
Что такое DevOps, что нужно знать и сколько получают DevOps - специалисты?
5 лучших качеств Ansible
Легкость в изучении
По правде говоря, это одно из самых крутых качеств Ansible – изучить его можно за один вечер и уже запускать веб – сервер из YAML, например. Ansible задачи запускаются последовательно, что сильно облегчает траблшутинг конфигураций. Например, можно сделать Playbook для Ansible, который позволит получить минимальный веб сервер примерно так:
Создаем файл формата .yml и наполняем командами;
Установить через yum apache;
Запустить apache как сервис в операционной системе;
Скопировать в корень веб – сервера html страничку с заглушкой («Мы готовим информацию по сайту, скоро здесь все будет, бла бла бла..»);
Скорректировать iptables, открыв порты и сохранить конфигурацию;
Не сложно, не правда ли?
Написан на Python
Я, как автор статьи, подметил следующее: если мы возьмем 10 программистов, вероятность, что кто-то из них знает Python гораздо выше, чем то, что кто – то из них знает Ruby. Именно это делает Ansible крутым – он написан на питоне в отличие от Ruby – based конкурентов. Так же отмечу, что Python библиотека, обычно, по умолчанию присутствует в любом Linux дистрибутиве, чего не сказать о Ruby.
Продолжая экскурсию – Ansible поддерживает написание модулей на любом языке программирования. Единственное требование – формат ответа. Это должен быть JSON.
Не нужно ставить клиента (агента) на машину
Для управления узлами, Ansible обрабатывает все коммуникации между мастер – узлами и узлами – агентами по стандартному SSH, или через модуль Paramiko, который является частью Python SSH второй версии.
Не нужно ставить агентское ПО на удаленные машины – только SSH подключение. Как следствие, упрощение обслуживания и траблшутинга.
YAML плейбуки
Как мы писали ранее, плейбуки в Ансибл невероятно просты и читаемы. Все DevOps инженеры, с которыми мы обсуждали его, освоили их за один вечер. Они даже проще чем JSON :)
Портал Ansible Galaxy
Портал, на котором вы наверняка найдете решение для своей задачи. Это объединение Ansible сообщества, где люди делятся наработками и решениями той или иной задачи. Знаете, это как ответ на мэйл.ру - чтобы вам не пришло реализовать на Ансибл, то как правило, кто – то эту задачу уже решил :). Тонны плейбуков, фреймворков, дистрибутивов и сопутствующего ПО.
5 худших качеств Ansible
Настало время хорошенько пройтись по Ansible и выделить минусы продукта. Пожестим.
Проблемы с интерфейсом (UI)
Изначально Ansible разработан для работы с командной строкой. Первые наметки в сторону визуализации конфигурации Ансибл начались через AWX – графический интерфейс пользователя, который являлся первой попыткой упрощения конфигураций через интерфейсную составляющую. В последствии, AWX превратился в Anbile Tower, который дает возможность через GUI управлять Ansible, рисовать workflow и так далее.
Несмотря на улучшение Tower перед AWX, он все равно позволяет делать только 85% рабочего функционала Ansible, который можно делать через командную строку. В добавок, конфигурации внесенный через интерфейс зачастую не синхронизируются с CLI – конфигами.
Ansible Tower находится на стадии разработки и пока весьма сыроват.
Нет работы с состоянием машин/процессов
Если сравнивать с тем же Puppet, Ansible не имеет понятия «состояние» и, соответственно, не отслеживает его. Ансибл не смотрит на зависимости, а просто выполняет последовательный ряд задач/процессов. Для кого – то это нормально и удовлетворяет поставленным задачам, но есть и другие пользователи, у которых от такой работы, мягко говоря, «подгорает» :)
Слабая поддержка совместимости с Windows
С версии 1.7 Ansible умеет работать с Unix и Windows узлами, но надо признаться, работа с первыми реализована гораздо лучше. Взаимодействие с Windows машинами происходит через PowerShell, и, что важно, вам все равно потребуется Linux хост (управляющая тачка) для такой коммуникации.
Ждем, когда Ansible разрабы разгребут бэклог по работе продукта с Windows.
Поддержка крупного бизнеса
Ansible Enterprise Tower и Premiun Tower имеют 8х5х4 и 24х7х2 SLA соответственно, но имеют меньше опыта поддержки крупняков, в сравнении, например, с Chef и Puppet.
Новизна продукта
Ansible находится на рынке меньше своих конкурентов и, само собой, баги будут всплывать. К тому же, комьюнити Ансибл только растет и развивается, в отличие от более крупных игроков, упомянутых в этой статье.
Итоги
Подведем черту: Ansible это просто, гибкий и мощный инструмент, для управления конфигами и автоматизацией. Ansible Tower имеет графический веб – интерфейс, REST API, с помощью которого вы можете интегрировать свой сторонние приложения и поддержку, которая только учится и осваивает азы сопровождения крупного энтерпрайза.
Ansible – новинка, которая имеет своих ранних последователей, противников, сторонников. Сочетая в себе большое количество плюсов, он, конечно, имеет ряд недостатков или так сказать «ранних болезней», через которые уже прошли более крупные конкуренты.
Но кто знает, что покажет нам Ansible завтра?
Привет всем! Многие читатели просили написать статью по настройке китайских GSM-шлюзов GoIP. Ну что же – это она :)
Мы постараемся как можно подробнее описать процесс настройки GSM-шлюза GoIP 1 и соединим его с IP-АТС Asterisk с помощью графического интерфейса FreePBX 14. Если у вас останутся вопросы или возникнут проблемы с настройкой, то мы поможем их решить в комментариях к данной статье!
Вся линейка оборудования GoIP различается в зависимости от количества SIM-карт, которые они поддерживают, а следовательно, и возможных GSM каналов. Есть модели GoIP 1/4/8/16 и 32.
$dbName_ecom = "to-www_ecom";
$GoodID = "3574205354";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName_ecom) or die(mysql_error());
$query_ecom = "SELECT `model`, `itemimage1`, `price`, `discount`, `url`, `preview115`, `vendor`, `vendorCode` FROM `items` WHERE itemid = '$GoodID';";
$res_ecom=mysql_query($query_ecom) or die(mysql_error());
$row_ecom = mysql_fetch_array($res_ecom);
echo 'Кстати, купить '.$row_ecom['vendor'].' '.$row_ecom['vendorCode'].' можно в нашем магазине Merion Shop по ссылке ниже. С настройкой поможем 🔧
Купить '.$row_ecom['model'].''.number_format(intval($row_ecom['price']) * (1 - (intval($row_ecom['discount'])) / 100), 0, ',', ' ').' ₽';
$dbName = "to-www_02";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName) or die(mysql_error());
Пошаговое видео
Немного теории
GoIP 1, как и вся линейка оборудования GoIP – это межсетевой шлюз, который работает на стыке сетей IP и GSM. Сама аббревиатура GoIP означает GSM Over IP. Таким образом, любую сеть IP-телефонии можно связать с сетью подвижной сотовой связи - GSM и использовать её как выход на телефонную сеть общего пользования (ТфОП).
Для того, чтобы GSM-шлюзом можно было пользоваться, в него нужно вставить простую SIM-карточку. Форм-фактор должен быть именно mini-SIM.
Сейчас объясним совсем просто. У всех есть мобильный телефон. Чтобы с него можно было звонить и принимать вызовы, мы вставляем в него SIM-карту, которой присвоен номер. Встроенная антенна в нашем телефоне находит сотовую сеть и с помощью SIM-карточки идентифицируется в ней. Теперь мы можем звонить и принимать звонки на наш номер со всего мира.
А теперь мы вытаскиваем SIM-карту из телефона и вставляем её в шлюз GoIP. Что поменялось? Да по сути - ничего. Шлюз также найдёт и также идентифицируется в сотовой сети. Останется только настроить его и “подружить” с нашей IP-АТС и мы сможем звонить c IP-телефона во внешний мир и принимать звонки от туда.
Закрепим всё это схемой:
Подготовка к настройке
Для начала нужно вставить в шлюз SIM-карточку. На задней панели есть специальный слот, вставьте туда mini-SIM-карточку как показано на картинке ниже.
Внимание! Прежде чем вставлять SIM-карты в шлюзы GoIP, слоты должны быть обесточены. Сделать это можно либо отключив питание шлюза, либо отключив питание соответствующего GSM модуля через веб - интерфейс
Всё оборудование линейки GoIP настраивается с помощью встроенного графического интерфейса. Для того, чтобы в него попасть нужно подключить шлюз в сеть через один из Ethernet портов, расположенных на корпусе шлюза. Шлюз имеет 2 Ethernet порта:
PC - порт может работать как в режиме моста, так и в режиме маршрутизатора. По умолчанию он находится в режиме маршрутизатора и ему присвоен адрес 192.168.8.1/24. Можно назначить на компьютере адрес из той же подсети, подключиться к шлюзу напрямую и получить доступ к веб интерфейсу по упомянутому адресу. В режиме моста шлюз можно подключить к локальной сети;
LAN - порт для подключения к локальной сети. По умолчанию он получает адрес по DHCP и для того, чтобы выяснить какой адрес он получил, можно воспользоваться одним из следующих методов:
Наберите номер SIM-карточки, которую вы вставили в шлюз. Как только будет ответ, наберите комбинацию *01. IP адрес, который получил шлюз, будет продиктован в трубку;
Отправьте на номер SIM-карты SMS сообщение с текстом ###INFO###, в ответ шлюз пришлет адрес, который получил по DHCP.
Если у вас есть доступ к DHCP серверу, вы можете узнать IP адрес шлюза через него;
Как только вы узнали адрес шлюза, введите его в адресную строку Вашего браузера. Логин и пароль по умолчанию - admin/admin.
Первая страница, которая переда нами откроется - это текущий статус шлюза. Если SIM-карта уже была вставлено, то мы увидим примерно следующее:
Рассмотрим, что означают данные поля:
CH/ Line - Номер канала и линии. У нас модель GoIP 1, поэтому мы видим статус только для одного поддерживаемого канала;
M - Статус GSM модуля. Y - значит включён, N - выключен. Если нажать на Y - то данный модуль выключится, и перейдёт в статус N. Соответственно, чтобы включить его, нужно будет нажать N. Прежде чем вставлять или вытаскивать SIM-карту из рабочего шлюза, необходимо выключить GSM модуль;
SIM - Статус наличия SIM-карты в слоте;
GSM - Статус регистрации шлюза в сети GSM;
VOIP - Статус регистрации в сети VoIP, то есть – регистрация на IP-АТС. Мы ещё не проводили никаких настроек, поэтому наш шлюз пока "не видит" IP-АТС;
Status - Статус VoIP линии. Изменяется в зависимости от VoIP активностей, которые происходят на шлюзе. Может показывать активный звонок (CONNECTED), входящий звонок (INCOMMING), исходящий звонок через соответствующий GSM канал (DIALING) и другие. Статус IDLE означает, что на шлюзе нет текущих VoIP активностей на соответствующем GSM канале;
SMS - Статус регистрации на сервере SMS;
ACD(S)/ASR(%)/Duration(S)/Count - Показывают соответственно: среднюю продолжительность звонка, средний коэффициент успеха отвеченных вызовов, продолжительность вызова, текущее количество активных звонков и общее число;
CDR Start- Время начала записей CRD;
RSSI - Показатель уровня принимаемого сигнала;
Carrier - Оператор сотовой связи. В нашем случае это МТС;
BST ID - Идентификатор базовой станции;
Idle - Время в минутах, прошедшее с момента последнего звонка;
Remain - Возможное оставшееся время для совершения исходящих звонков;
SMS Remain - Количество оставшихся SMS, которые можно отправить;
Reset - Данная вкладка позволяет сбросить показатели полей, рассмотренных выше;
Итак, прежде чем приступать к настройке, предлагаем обновить прошивку на нашем шлюзе до актуальной версии. Для этого открываем вкладку Tools → Online Upgrade. Выясняем текущую версию, а затем идём на сайт производителя - http://www.hybertone.com/en/news_detail.asp?newsid=21 и ищем более актуальную версию для своей модели (в нашем случае – GoIP 1):
Копируем ссылку, для своей модели, вставляем её в строку Upgrade Site в интерфейсе нашего шлюза и жмём Start
Внимание! В процессе обновления нельзя перезагружать или отключать питание шлюза!
Дождитесь пока завершится процесс обновления, устройство перезагрузится автоматически.
После перезагрузки, Вы увидите уведомление о том, что обновление прошло успешно и новую версию прошивки:
Настройка на стороне GoIP
Итак, прыгаем в Configurations → Preferences. Здесь меняем часовую зону и отключаем встроенный IVR. После завершения настроек на каждой вкладке интерфейса необходимо подтверждать изменения кнопкой Save Changes
Далее переходим на вкладку Network и меняем настройки IP адресации на статические LAN Port → Static IP
Теперь переходим на вкладку Basic VoIP и настраиваем подключение к серверу Asterisk.
Endpoint Type оставляем как SIP Phone;
Config Mode также не трогаем, оставляем Single Server Mode;
В полях Authentication ID, Display Name и Phone Number обязательно нужно правильно указать название SIP-аккаунта, который мы потом заведём на FreePBX. Данные поля необходимы для успешной SIP регистрации. В нашем случае SIP-аккаунт называется goip-merion;
В поле Password указываем пароль для доступа к транку. Точно такой же нам нужно будет ввести на при настройке на стороне FreePBX;
Самый важный момент - SIP Registrar и SIP Proxy. Сюда вводим IP адрес нашего сервера Asterisk и порт, на котором он слушает Chan_SIP. По умолчанию, драйвер chan_sip работает на порту 5160;
Проверить это можно через FreePBX в модуле Asterisk SIP Settings. Перейдите на вкладку Chan SIP Settings и проверьте поле Bind Port. Впишите тот порт, который там указан или же, измените его значение и впишите его на GoIP.
Таким образом, если IP адрес Вашего Asterisk 192.168.12.34, то в поля SIP Registrar и SIP Proxy вводите 192.168.12.34:5160. Нажимаем Save Changes
На вкладке Advanced VoIP есть важный момент. Обратите внимание на поле Signaling Port. Это порт, на котором шлюз слушает SIP, по умолчанию его значение 5060. При настройке транка на стороне FreePBX нужно будет это учесть.
В поле Call OUT Auth Mode выберем опцию IP and Password, отметим опцию As Proxy и введём пароль. Такой же пароль потом будет необходимо ввести при настройке транка.
Далее на очереди вкладка Media. На ней настроим интервал RTP портов как на Asterisk (10000-20000), а также приоритетность кодеков:
Вкладку Call Out и Call Out Auth оставляем без изменений. На вкладке Call In меняем 2 параметра:
CID Forward Mode - устанавливаем значение Use CID as SIP Caller ID для того, чтобы определялся номер звонящего;
Forwarding to VoIP Number - вписываем сюда номер нашей IP-АТС, куда будут приходить входящие звонки. В нашем случае – это будет внутренний номер 175, который мы создадим на FreePBX;
На этом, настройка на стороне шлюза GoIP закончена. Теперь переходим во FreePBX.
Настройка на стороне FreePBX
Прежде чем приступать к настройкам на стороне FreePBX, предлагаю внести IP-адрес шлюза в белый список fail2ban. В процессе регистрации от шлюза может прийти много неудачных попыток регистрации. Из-за этого он может быть просто заблокирован fail2ban’ом и Asterisk не сможет его даже пинговать. Чтобы этого избежать, рекомендую сделать следующее:
Подключитесь к Asterisk через ssh и откройте для редактирования файл /etc/fail2ban/jail.local, например, с помощью vim:
vim /etc/fail2ban/jail.local
Найдите секцию [DEFAULT] и добавьте в опцию ignoreip адрес шлюза GoIP, который настроили ранее. Адреса можно добавлять через пробел в одну строку, можно также добавлять целые сети. На примере ниже, мы внесли адрес шлюза 192.168.12.34/24
Теперь мы готовы. Сначала настроим новый транк. Для этого открываем раздел Connectivity → Trunks → Add Trunk → Add SIP (chan_sip) Trunk. На вкладке General указываем название и вписываем номер, который присвоен SIM-карточке:
Далее переходим на вкладку sip Settings → Outgoing. Указываем имя транка в Trunk Name и заполняем PEER Details следующим образом:
Обратите внимание, что параметр port=5060, он должен совпадать с тем, что указан в Signaling Port на GoIP. Для удобства, приводим PEER Details ниже:
host="IP Шлюза GoIP"
port=5060
type=peer
context=from-internal
dtmfmode=rfc2833
disallow=all
allow=alaw&ulaw
insecure=very&port,invite
qualify=yes
defaultuser=goip-merion
secret="Ваш Пароль"
nat=no
canreinvite=no
Теперь переходим на вкладку sip Settings → Incoming. Указываем имя SIP-аккаунта USER Context, оно должно совпадать с Authentication ID, Display Name и Phone Number на GoIP. Затем заполняем USER Details следующим образом:
type=friend
host=dynamic
secret="Ваш Пароль"
context=from-trunk
dtmfmode=rfc2833
canreinvite=no
qualify=yes
После выполненных настроек, рекомендую перезагрузить шлюз.
После этого, в Asterisk Info у нас должно появиться что-то типа:
Это значит, что регистрация шлюза прошла успешно. Обратите внимание, что мы уже создали внутренний номер 175. Если мы откроем статус GoIP, то также увидим там подтверждение того, что транк был успешно зарегистрирован:
Нам осталось только создать исходящий маршрут и настроить отправку исходящих вызовов в транк к GoIP шлюзу:
А также обозначить в нём правила набора:
При этом, входящий маршрут нам не нужен, так как при настройке GoIP в разделе Call In → Forwarding to VoIP Number мы настроили приём всех входящих звонков на номер 175. На данном номере, мы зарегистрировали софтфон DrayTek, попробуем сделать исходящий вызов:
Работает
А теперь попробуем позвонить на номер SIM-карточки, которую мы вставили в шлюз:
Вызов попадает на тот же DrayTek с номером 175. Номер звонящего определяется.
На этом настройка шлюза GoIP 1 завершена. Надеюсь, что данная статья была Вам полезна. Пишите в комментарии, если столкнулись с проблемой!
В первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложения. Настало время более детально рассмотреть HTTP и REST.
Понимание HTTP имеет решающее значение для веб-разработчиков, поскольку оно облегчает поток информации в веб-приложении, позволяя улучшить взаимодействие с пользователями и повысить производительность сайта.
Что такое HTTP?
В клиент-серверной модели клиенты и серверы обмениваются сообщениями по принципу «запрос-ответ»: клиент отправляет запрос, а сервер возвращает ответ.
Хранить трек из этих сообщений сложнее, чем звучит, поэтому клиент и сервер придерживаются общего языка и набора правил. Этот «язык», или протокол, называется HTTP.
Протокол HTTP определяет синтаксис (формат и кодировку данных), семантику (значение, связанное с синтаксисом) и тайминг (скорость и последовательность). Каждый HTTP-запрос и ответ, которыми обмениваются клиент и сервер, рассматривается как одна HTTP-транзакция.
HTTP: Общая информация
Есть несколько вещей, которые стоит отметить про HTTP, прежде чем погрузиться в детали.
Во-первых, HTTP текстовый протокол, что означает, что сообщения, которыми обмениваются клиент и сервер, являются битами текста. Каждое сообщение содержит две части: заголовок и тело.
Во-вторых, HTTP - это протокол прикладного уровня, то есть это просто абстракционный уровень, который стандартизирует взаимодействие хостов. Сам HTTP не передает данные. Получение запроса и ответа от одной машины к другой по-прежнему зависит от базового протокола TCP/IP.
Напоминаем, что TCP/IP - это двухкомпонентная система, которая функционирует как фундаментальная «система управления» Интернета.
Наконец, возможно, вы видели протокол «HTTPS» в адресной строке браузера и интересовались, является ли HTTP тем же самым, что HTTP + «S». Если коротко, то HTTPS разновидность HTTP, с небольшой разницей.
Простой HTTP-запрос или ответ не зашифрован и уязвим для различных типов атак. HTTPS, напротив, является более безопасной протоколом связи, которая использует TLS/SSL шифрование для обеспечения безопасности.
SSL - это протокол безопасности, который позволяет клиенту и серверу взаимодействовать по сети безопасным способом - чтобы предотвратить сниффинг и подмену во время передачи сообщений по сети.
Клиент обычно указывает, требуется ли ему подключение TLS/SSL, используя специальный номер порта 443. Как только клиент и сервер соглашаются использовать TLS/SSL для обмена данными, они согласовывают соединение с отслеживанием состояния, выполняя так называемое «квитирование TLS». Затем клиент и сервер устанавливают секретные сеансовые ключи, которые они могут использовать для шифрования и дешифрования сообщений, когда они разговаривают друг с другом.
Многие крупные веб-сайты, такие как Google и Facebook, используют HTTPS - в конце концов, это то, что сохраняет ваши пароли, личную информацию и данные кредитных карт в безопасности.
Что такое API
HTTP: Углубляясь в детали
Теперь, вооружившись базовыми знаниями, погрузимся глубже в структуру HTTP.
Мы можем начать с посещения https://www.github.com, чтобы связаться с сервером GitHub. Если вы используете Chrome или Firefox с установленным расширением Firebug, вы можете подробно изучить HTTP-запрос, перейдя на вкладку «Сеть» или «Network». С открытой кладкой «Сеть», перейдите на сайт www.github.com, введя его в адресную строку, и вы должны увидеть что-то подобное:
Затем на левой панели щелкните по первому пути, «github.com.» Теперь вы должны увидеть следующее:
Заголовок запроса HTTP
Заголовки HTTP обычно содержат метаданные (данные о данных). Метаданные включают тип запроса (GET, POST, PUT или DELETE), путь, код состояния, тип содержимого, используемый браузер, cookie, текст сообщения (иногда) и многое другое.
Рассмотрим наиболее важные части заголовка на примере GitHub, начиная с раздела «Заголовки ответа»:
Request URL: https://github.com/ - Запрошенный URL-адрес
Request Method: GET - Тип используемого метода HTTP. В нашем случае наш браузер сказал: «Эй, сервер GitHub, я хочу ПОЛУЧИТЬ (GET) домашнюю страницу».
Status Code:200 OK - Стандартизированный способ информирования клиента о результате запроса. Код состояния 200 означает, что сервер успешно нашел ресурс и отправляет его вам.
Remote Address:192.30.252.129:443 - IP-адрес и номер порта веб-сайта GitHub, который мы посетили. Обратите внимание, что это порт номер 443 (это означает, что мы используем HTTPS вместо HTTP).
Content-Encoding: gzip - Кодировка ресурса, который мы получили обратно. В нашем случае сервер GitHub сообщает нам, что содержимое, которое он отправляет назад, сжато. Возможно, Github сжимает файлы, чтобы страница быстрее загружалась.
Content-Type: text/HTML; charset = utf-8 - Задает представление данных в теле ответа, включая тип и подтип. Тип описывает тип данных, в то время как подтип указывает конкретный формат для этого типа данных. В нашем случае, мы имеем текст, в формате HTML. Во второй части указывается кодировка символов для HTML-документа. Чаще всего это будет UTF-8, как и выше.
Есть также куча информации заголовка, которую клиент должен был отправить, чтобы сервер мог знать, как ответить. Посмотрите на раздел «Заголовки запросов» или «Headers»:
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 - Программное обеспечение, которым пользуется пользователь. Иногда веб-сайт должен знать, с какого устройства он просматривается. Поэтому браузер отправляет эту последовательность User-Agent, которую сервер может использовать для определения того, что используется для доступа к веб-сайту
Accept-Encoding: gzip, deflate, sdch - Указывает кодировку содержимого, которую может обработать браузер. Мы видим, что указан gzip, и поэтому сервер Github смог отправить нам содержимое в формате gzip.
Accept-Language: en-US, en; q = 0.8 - Описывает язык, на котором должна отобразиться веб-страница. В нашем случае «en» означает английский.
Host: github.com - Описывает хост, на который мы идем
Cookie:_octo=GH1.1.491617779.1446477115; logged_in=yes; dotcom_user=iam-peekay; _gh_sess=somethingFakesomething FakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFake; user_session=FakesomethingFake somethingFakesomethingFakesomethingFake; _ga=9389479283749823749; tz = America% 2FLos_Angeles _ - Фрагмент текста, который веб-сервер может хранить на компьютере пользователя и впоследствии извлекать. Информация сохраняется как пара имя-значение. Например, одна из пар имя-значение, сохраненных GitHub для моего запроса, является «dotcom_user=iam-peekay,», которая сообщает GitHub, что мой userid – Iam-peekay.
Что теперь со всеми этими парами имя-значение?
Итак, у нас есть много пар имя-значение. Но как создаются эти пары имя-значение?
Каждый раз, когда браузер будет открывать веб-сайт, он будет искать на компьютере файл cookie, установленный веб-сайтом ранее.
Так что, при посещении www.github.com, браузер будет искать файл cookie, который GitHub сохранил на жестком диске компьютера пользователя. Если он найдет файл cookie, он отправит все пары имя-значение в заголовке запроса.
Веб-сервер GitHub теперь может использовать данные cookie различными способами, такими как рендеринг контента на основе сохраненных пользовательских предпочтений, подсчет количества времени, проведённого на сайте.
Если браузер не находит файл cookie - либо потому, что сайт никогда не посещался, либо пользователь заблокировал или удалил его - браузер не отправляет данные cookie.
В этом случае сервер GitHub создает новый идентификатор в качестве пары имя-значение, вместе с любыми другими необходимыми ему парами имя-значение, и отправляет его пользователю через заголовок HTTP. Получив данные, устройство хранит их на своем жестком диске.
Тело HTTP
Выше мы узнали, что сервер содержит большинство важных «метаданных» (данные о данных), которые необходимы для связи с клиентом.
Теперь поговорим о теле HTTP запроса.
Тело – это основная часть сообщения. В зависимости от типа запроса он может быть и пустым.
В нашем случае вы можете увидеть тело на вкладке «Response». Поскольку мы сделали запрос GET на www.github.com, тело содержит содержимое HTML-страницы для www.github.com.
Дополнительные упражнения
Надеюсь, такой разбор позволит вам лучше понять структуру HTTP. На практике вы можете просмотреть на другие ресурсы, запрашиваемые вашим браузером (изображения, файлы JavaScript и т.д.) при посещении www.github.com.
Теперь рассмотрим различные методы HTTP запросов, которые клиент может инициировать.
Методы HTTP
Команды или методы HTTP указывают серверу, что делать с данными, определенными по URL. URL-адреса всегда идентифицируют определенный ресурс. Когда клиент использует URL-адрес в сочетании с командой HTTP, это сообщает серверу, какое действие необходимо выполнить с указанным ресурсом.
Примеры URL-адресов:
GET http://www.example.com/users (получить всех пользователей)
POST http://www.example.com/users/a-unique-id (создание нового пользователя)
PUT http://www.example.com/comments/a-unique-id (обновить комментарий)
DELETE http://www.example.com/comments/a-unique-id (удалить комментарий)
Когда клиент делает запрос, он указывает тип запроса, используя одну из этих команд. Наиболее важными являются GET, POST, PUT и DELETE. Есть и другие методы, такие как HEAD и OPTIONS, но они используются редко, поэтому в данном материале мы пропустим их.
GET
GET является наиболее часто используемым методом. Он используется для чтения информации по данному URL-адресу с сервера.
Запросы GET доступны только для чтения, что означает, что данные никогда не должны быть изменены на сервере - сервер должен просто извлечь данные без изменений. Таким образом, запросы GET считаются безопасными операциями, поскольку сколько бы не вызывай его, ответ будет одинаковым.
Кроме того, запросы GET являются идемпотентными. Это означает, что отправка нескольких запросов GET на один и тот же URL-адрес должна привести к тому же эффекту, что и один запрос GET, поскольку запрос GET просто запрашивает данные с сервера, а не изменяет их.
Запросы GET отвечают кодом состояния 200 (ОК), если ресурс был успешно найден, и 404 (NOT FOUND), если ресурс не был найден. (Отсюда термин «404 page» для сообщений об ошибках при посещении несуществующих или неправильно набранных URL-адресов.)
POST
POST используется для создания нового ресурса, например, через форму регистрации. Функция POST используется при необходимости создания дочернего ресурса (например, нового пользователя) для какого-либо родительского ресурса (http://example.com/users). Родительский ресурс запроса на создание новой сущности определяется по URL-адресу, и сервер обрабатывает новый ресурс и связывает его с родительским ресурсом.
POST не является ни безопасным, ни идемпотентным. Это связано с тем, что выполнение двух или более идентичных запросов POST приведет к созданию двух новых идентичных ресурсов.
Запросы POST отвечают кодом состояния 201 (CREATED) вместе с заголовком местоположения со ссылкой на вновь созданный ресурс.
PUT
PUT используется для обновления ресурса, идентифицированного по URL, с использованием информации в теле запроса. PUT также может использоваться для создания нового ресурса. Запросы PUT не считаются безопасными операциями, поскольку они изменяют данные на сервере. Однако он является идемпотентным, поскольку несколько идентичных запросов PUT на обновление ресурса должны иметь тот же эффект, что и первый.
Запросы PUT отвечают кодом состояния 200 (OK), если ресурс был успешно обновлен, и 404 (NOT FOUND), если ресурс не был найден.
DELETE
DELETE используется для удаления ресурса, определенного по URL-адресу. Запросы DELETE являются идемпотентным, поскольку если УДАЛИТЬ ресурс, он будет удален, и даже если вы сделаете несколько идентичных запросов DELETE, результат будет одинаковым: удаленный ресурс.
Скорее всего, вы просто получите сообщение об ошибке 404, если отправить запрос DELETE для одного и того же ресурса несколько раз, поскольку сервер не сможет найти его после удаления.
Запросы DELETE отвечают кодом состояния 200 (OK) в случае успешного удаления или 404 (NOT FOUND), если не удалось найти удаляемый ресурс.
Все вышеуказанные запросы возвращают значение 500 (ВНУТРЕННЯЯ ОШИБКА СЕРВЕРА), если обработка завершается неуспешно и сервер выдаёт ошибку.
Что же такое REST?
Перейдем к последнему термину – REST.
Возможно, вы слышали термин RESTful application ранее. Важно понимать, что это означает, потому что, если вы используете HTTP для обмена данными между клиентом и сервером, полезно следовать рекомендациям REST. На самом деле, HTTP-методы, которые мы рассмотрели выше, не что иное, как часть REST.
REST расшифровывается как Representational State Transfer (Передача состояния представления). Это архитектурный стиль проектирования приложения.
Основная идея заключается в том, что для выполнения вызовов между машинами используется протокол «без состояния», «клиент-сервер», «кэшируемый» - и чаще всего этот протокол HTTP. В общем, REST это согласованный набор ограничений для проектирования приложения. Эти ограничения помогают сделать систему более производительной, масштабируемой, простой, изменяемой, видимой, портативной и надежной.
Полный список ограничений очень длинный, и вы можете прочитать об этом здесь. В этой статье остановимся на двух наиболее важных из них:
1. Унифицированный интерфейс - Uniform interface: это ограничение позволяет определить интерфейс между клиентом и сервером путь, чтобы упростить и разъединить архитектуру. Там написано, что:
Ресурсы должны быть идентифицируемыми в запросе (например, с помощью идентификаторов ресурсов в URI). Ресурс (например, данные в базе данных) - это данные, которые определяют представление ресурса (например, JSON, HTML). Ресурсы и представления ресурсов - это концептуально разные сущности - клиент взаимодействует только с представлением ресурсов.
Клиент должен иметь достаточно информации для управления ресурсами на сервере с помощью представления ресурса.
Каждое сообщение, которым обмениваются клиент и сервер, должно быть самоописательным и содержать информацию о том, как обрабатывать сообщение.
Клиенты должны отправлять данные о состоянии с использованием основного содержимого HTTP, заголовка HTTP-запроса, параметров запроса и URL-адреса. Серверы должны отправлять данные о состоянии с помощью тела HTTP, кодов ответов и заголовков ответов.
Примечание: Описанные выше команды HTTP составляют основную часть ограничения «унифицированного интерфейса», поскольку они представляют собой единообразные действия, которые происходят с ресурсами.
2. Отсутствие состояния - Stateless: это ограничение говорит о том, что все данные о состоянии, необходимые для обработки запроса клиента, должны содержаться в самом запросе (URL, параметры запроса, тело HTTP или заголовки HTTP), а сервер должен отправить все необходимые данные о состоянии клиенту через сам ответ (заголовки HTTP, код состояния и тело ответа HTTP).
Примечание: Состояние - или состояние приложения - это данные, необходимые серверу для выполнения запроса.
Это означает, что для каждого запроса мы пересылаем информацию о состоянии туда и обратно, так что сервер не должен поддерживать, обновлять и отправлять состояние.
Наличие системы без сохранения состояния делает приложения намного более масштабируемыми, потому что ни один сервер не должен беспокоиться о поддержании одного и того же состояния сеанса на протяжении нескольких запросов. Все необходимое для получения данных о состоянии доступно в самом запросе и ответе.
Заключение
HTTP далеко не прост. Но, как вы видите, это критически важный компонент отношений между клиентом и сервером.
Для создания RESTful приложений требуется по крайней мере базовое понимание HTTP. С таким багажом знаний, следующий проект для вас будет намного проще.