По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В предыдущей части нашей серии OSPF мы рассмотрели варианты ручной фильтрации маршрутов. Теперь мы обсудим маршруты по умолчанию и сравним OSPFv2 с OSPFv3. Предыдущие статьи: Расширенные возможности OSPF: Области OSPF: создание конкретных типов областей Ручная фильтрация маршрутов OSPF Маршрут по умолчанию (Default Routes) Мы изучили с вами, что OSPF может автоматически генерировать маршрут по умолчанию, когда это необходимо. Это происходит с некоторыми специальными типами областей. Например, если вы настраиваете totally stubby area, требуется маршрут по умолчанию, и OSPF генерирует этот маршрут автоматически из ABR. Чтобы повысить гибкость ваших проектов, маршруты по умолчанию, вводимые в нормальную область, могут быть созданы любым роутером OSPF. Для создания маршрута по умолчанию используется команда default-information originate. Эта команда содержит два варианта: Вы можете объявлять 0.0.0.0 в домен OSPF, при условии, что объявляемый роутер уже имеет маршрут по умолчанию. Вы можете объявлять 0.0.0.0 независимо от того, имеет ли объявляемый роутер уже маршрут по умолчанию. Этот второй метод выполняется путем добавления ключевого слова always к default-information originate Рисунок 1 - топология OSPF Используя нашу простую топологию из рисунка 1 еще раз, давайте настроим ATL2 для введения маршрута по умолчанию в нормальную, не магистральную область 1. ATL2#conf t Enter configuration commands, one per line. End with CNTL/Z . ATL2 (config)#router ospf 1 ATL2 (config-router)#default-information originate always ATL2 (config-router)#end ATL2# Обратите внимание, что в этом примере мы используем ключевое слово always, чтобы убедиться, что ATL2 генерирует маршрут по умолчанию независимо от того, есть ли у устройства уже маршрут по умолчанию в его таблице маршрутизации. Вот проверка на ORL: show ip route Сравнение OSPFv2 и OSPFv3 Каким бы удивительным ни был OSPFv2, он не может маршрутизировать префиксы IPv6 для нас. Это работу выполняет OSPFv3. Хорошей новостью для вас является тот факт, что вы можете использовать почти все, что вы узнали о OSPFv2 при переходе на протокол OSPFv3. Полная перестройка протокола не проводилась, и было сохранено как можно больше функциональных возможностей и этапов настройки. Как вы узнаете далее, OSPFv3 предлагает использование семейств адресов в конфигурации, что делает этот протокол подходящим для переноса префиксов IPv6 или даже префиксов IPv4 с соответствующим семейством адресов. В конце этой статьи демонстрируется «стандартная» конфигурация OSPFv3, а также конфигурация семейства адресов. Важно иметь представление о ключевых сходствах и различиях между v2 и v3 протоколов OSPF. Вот сходства, которые описаны ниже: В OSPFv3 процесс маршрутизации не создается явно. Включение OSPFv3 на интерфейсе приведет к созданию процесса маршрутизации и связанной с ним конфигурации. Идентификатор маршрутизатора по-прежнему является 32-разрядным значением в OSPFv3, и процесс выбора идентификатора маршрутизатора остается таким же. OSPF автоматически предпочитает loopback интерфейс любому другому виду, и он выбирает самый высокий IP-адрес среди всех loopback интерфейсов. Если никаких loopback интерфейсов нет, то выбирается самый высокий IP-адрес в устройстве. Вот некоторые ключевые отличия: Эта функция отличается от OSPF версии 2, в которой интерфейсы косвенно включены с помощью режима конфигурации устройства. При использовании nonbroadcast multiaccess интерфейса в OSPFv3 необходимо вручную настроить устройство со списком соседей. Соседние устройства идентифицируются по их идентификатору устройства. В IPv6 можно настроить множество префиксов адресов на интерфейсе. В OSPFv3 все префиксы адресов на интерфейсе включены по умолчанию. Вы не можете выбрать определенные префиксы адресов для импорта в OSPFv3; либо импортируются все префиксы адресов в интерфейсе, либо никакие префиксы адресов в интерфейсе не импортируются. В отличие от OSPF версии 2, несколько экземпляров OSPFv3 могут быть запущены на линии. Традиционная (стандартная) настройка OSPFv3 Чтобы продемонстрировать (и попрактиковать) конфигурацию OSPFv3 часть настроек мы отбросили. Вот конфигурация нашей магистральной области (область 0) и не магистральной области (область 1) с использованием «традиционного» подхода OSPFv3. ATL# configuration terminal Enter configuration commands, one per line . End with CNTL/Z . ATL(config)#ipv6 unicast-routing ATL(config)#interface fa0/0 ATL(config-if)#ipv6 address 2001:1212:1212::1/64 ATL(config-if)#ipv6 ospf 1 area 0 ATL(config-if)#interface loopback0 ATL(config-if)#ipv6 address 2001:1111:1111::1/64 ATL(config-if)#ipv6 ospf 1 area 0 ATL(config-if)#end ATL# Обратите внимание, насколько знакомым кажется этот подход к настройке, он аналогичен настройке OSPFv2. Обратите внимание также, что мы должны глобально включить возможность одноадресной маршрутизации IPv6 на устройстве. Это не является действием по умолчанию. Вы также должны понять, что это не требуется для запуска IPv6 на интерфейсах, это просто требование сделать маршрутизацию трафика IPv6 на роутере. Вот конфигурация наших двух других устройств: ATL2#conf t Enter configuration commands, one per line. End with CNTL/Z . ATL2 (config)#ipv6 unicast-routing ATL2 (config)#int fa0/0 ATL2 (config-if)#ipv6 address 2001:1212:1212::2/64 ATL2 (config-if)#ipv6 ospf 1 area 0 ATL2 (config-if)# *Mar 28 09:23 :25 .563 : %0SPFv3-5-ADJCHG: Process 1, Nbr 192.168.20.1 on FastEthernet0/0 from LOADING to FULL, Loading Done ATL2 (config-if)#int fa1/0 ATL2 (config-if)#ipv6 address 2001:2323:2323::2/64 ATL2 (config-if)#ipv6 ospf 1 area 1 ATL2 (config-if)#end ATL2# ORL#conf t Enter configuration commands, one per line . End with CNTL/Z . ORL(config)#ipv6 unicast-routing ORL(config)#int fa1/0 ORL(config-if)#ipvб address 2001:2323:2323::3/64 ORL(config-if)#ipvб ospf 1 area 1 ORL(config-if)#end ORL# Теперь настало время для проверки. Обратите внимание, что я выполню все это на устройстве ORL для краткости. Обратите внимание еще раз на все замечательные сходства с OSPFv2: show ipv6 route show ipv6 ospf neighbor show ipv6 ospf database Конфигурация Семейства Адресов OSPFv3 Давайте завершим эту статью изучением стиля конфигурации семейства адресов OSPFv3. Помните, что это позволит нам использовать этот единый протокол для передачи префиксов IPv4 и IPv6. Вот пример подхода к конфигурации семейства адресов OSPFv3: BOS (config)#ipv6 unicast-routing BOS (config)#router ospfv3 1 BOS (config-router)#address-family ipv6 unicast BOS (config-router-af)#area 1 range 2001:DB8:0:0::0/128 BOS (config-router-af)#end BOS#conf t BOS (config)#interface fa1/0 BOS (config-if)#ipv6 ospf 1 area 1 Важно то, что если вы уже знакомы с семействами адресов из другого протокола (например, BGP), то эта настройка покажется вам очень простой. Также учтите, что подход к настройке OSPFv3 на подинтерфейсах не меняется.
img
Настроим VoIP-шлюз Eltex TAU-16.IP в качестве мини - АТС.Данное устройство нет смысла использовать как полноценную мини - АТС, так как в ней будут отсутствовать многие функции, но в некоторых случаях такой вариант тоже применим. $dbName_ecom = "to-www_ecom"; $GoodID = "3152129363"; 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_ecom = "to-www_02"; $GoodID = "3152129363"; mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение "); mysql_select_db($dbName_ecom) or die(mysql_error()); Главным достоинством шлюза является поддержка SIP-транков и наличие аналоговых портов FXS одновременно. Обычно Вы можете приобрести более доступную аналоговую мини - АТС с таким же количеством аналоговых портов, но возможность подключения входящих SIP-линий отсутствует или предполагает дополнительные затраты на лицензии или дополнительное оборудования. Или же Вы можете приобрести VoIP АТС с поддержкой SIP-транков и телефонов из коробки, и так же значительно дешевле. Но чтобы подключить к ней аналоговые телефоны необходимо докупить VoIP шлюз(ы) с количеством портов, соответствующим количеству аппаратов. В первую очередь следует настроить сеть. В самом простом случае, достаточно изменить адрес шлюза, который установлен по-умолчанию. Настройки выполняются в разделе "Сетевые настройки/Сеть": Если же необходимо разделить сеть для голоса и для управления, следует настроить сети на вкладке "VLAN", указав адреса для каждой сети, а так же указать, по каким сетям будет передаваться голос, сигнальная информация и осуществляться управление (указывается внизу страницы). Настройки выполняются в разделе "Сетевые настройки/VLAN": Общий принцип настройки устройства в качестве АТС заключается в следующем: создается два SIP-профиля, один из которых отвечает за связь с внешним миром (с оператором VoIP), а второй за работу аналоговых портов. В первом профиле задаются настройки транка для связи с оператором адрес сервера, порт, данные для регистрации (если требуется), поддерживаемые кодеки и план нумерации, согласно которому устройство будет отправлять вызовы на этот транк. Второй профиль создается без регистрации и дает возможность совершать вызовы по коротким номерам внутри шлюза. План набора этого профиля указывает устройству, какие вызовы выполняются внутри шлюза, а какие следует направлять во внешний мир. Итак, настройки профиля для связи с провайдером. Выполняются в разделе "PBX / Профили SIP/H323 / Профиль 1". Во вкладке "SIP настройки профиля": Здесь указываются данные, которые предоставляет оператор связи. Основные данные адрес, куда должен обращаться шлюз для совершения вызовов. Если используется транк с регистрацией, необходимо включить эту функцию в поле 1, и указать данные для регистрации (логин/пароль) в полях 2 и 3. Остальные настройки можно оставить по-умолчанию. Во вкладке "Кодеки" задаются используемые кодеки, а так же есть возможность задать настройки для передачи модема и факса. Эти данные так же обычно предоставляет оператор. В общем случае, у нас всегда должен работать кодек G.711a. Для успешного прохождения факсов обычно отключаем опцию "Передача модема", а в параметре "Основной кодек передачи факса" выбираем "Т38", резервный G.711a. Так же, с нашим оператором возникают проблемы с опциями "Эхокомпенсатор" и "Комфортный шум", поэтому их так же деактивируем. Переходим ко вкладке "План набора". Настройки на этой вкладке позволяют совершать вызовы через сеть нашего оператора. Здесь указываем префиксы, набрав которые, абонент должен звонить через внешнюю сеть. В данном случае, удобнее использовать опцию "Табличный план набора": Нажимаем кнопку "Добавить префикс": Указываем префикс, минимальное количество цифр в набираемом номере. В поле "Протокол и направление" в нашем случае указываем "SIP-транк" (транк по ip-адресу без регистрации). Тип номера Subscriber (при звонках внутри оператора связи) или National (при звонках на сеть МГ). На самом деле, вероятнее всего, на стороне оператора этот параметр все равно будет корректироваться. В поле "ip-адрес" указывается адрес станции оператора, на который обращается шлюз для выполнения вызовов. Этот же адрес указывался в настройках SIP-профиля. В форме "Абонентские порты" можно указать, какие именно абоненты могут выполнять вызовы по этому правилу. Переходим к настройке Профиля 2 (для локальных абонентов). Собственно, вся настройка сводится к настройке Плана набора, в основных настройках все поля оставляем по-умолчанию. Во вкладке "План набора" выбираем опцию "Строчный план набора" и вписываем следующую строчку: 1xx@192.168.130.58|x.@192.168.130.57 где: 1xx - нумерация, используемая для внутренних абонентов. В нашем случае, внутренние номера телефонов имеют вид 101,102, 103 и т.д. 192.168.130.58 локальный адрес нашего устройства. То есть, если внутренний абонент набирает номер вида 101, 102 и т.д., вызов осуществляется внутри устройства. x.@192.168.130.57 - данная строчка означает, что все остальные вызовы будут направляться на адрес 192.168.130.57 (адрес оператора), то есть через транк. Теперь настроим абонентские порты. Переходим на вкладку "PBX/Абонентские порты" В этой вкладке задаем внутренние номера, а в поле "SIP/H323 профиль" указываем тот профиль, который настраивали для внутренней связи ( в нашем случае, Профиль 2). После выполнения этих настроек исходящая связь уже должна работать. Остается настроить входящую связь. Следует помнить, что при настройке параметров на каждой вкладке следует нажимать кнопку "Применить изменения". После выполнения всех настроек необходимо нажать кнопку "Сохранить". В противном случае, после перезагрузки устройства настройки будут утеряны. Эту особенность так же можно использовать в случае, когда что-то пошло не так и необходимо вернуть исходные настройки. Перейдем к настройке входящих вызовов. Открываем вкладку "PBX/Группы вызова". Здесь нажимаем кнопку "Новая группа": Имя группы любое, пароль пропускаем, телефонный номер внешний номер, на который совершается вызов и который будет обозначен как B-номер во входящем вызове. Тип группы: групповой звонят все телефоны в группе, серийный после таймаута начинает звонить следующий телефон, при этом предыдущий продолжает звонить, циклический вызов по очереди переходит на следующий в списке порт. "SIP-профиль" - профиль, на котором работают внутренние номера (в нашем случае, Профиль 2). Кнопку "В работе" необходимо включить. После добавления группы вызова, ее нужно отредактировать: Для редактирования необходимо нажать иконку в столбце "Изменить". Здесь появилась новая вкладка "Порты", где можно добавлять или удалять порты, на которые будет поступать вызов и задавать очередность поступления вызова. На этом настройка шлюза Eltex TAU-16.IP закончена. Настройки применимы на всех устройствах серии ELTEX TAU стоечного исполнения (16,32,36,72 порта). Версия ПО в данном случае - 2.18.0.35
img
В первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложения. Настало время более детально рассмотреть 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. С таким багажом знаний, следующий проект для вас будет намного проще.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59