⚡ ѕ–ќ…ƒ» Ќќ¬џ… ќЌЋј…Ќ  ”–— ѕќ —≈“≈¬џћ “≈’ЌќЋќ√»яћ —ќ — »ƒ ќ… 50%

до конца скидки осталось

Ќачать обучение 🚀
ћерион Ќетворкс

12 минут чтени€

¬ первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложени€. Ќастало врем€ более детально рассмотреть HTTP и REST.

ќбучайс€ в Merion Academy

ѕройди курс по
сетевым технологи€м

Ќачать

ѕонимание 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 - в конце концов, это то, что сохран€ет ваши пароли, личную информацию и данные кредитных карт в безопасности.


HTTP: ”глубл€€сь в детали

“еперь, вооружившись базовыми знани€ми, погрузимс€ глубже в структуру HTTP.

ћы можем начать с посещени€ https://www.github.com, чтобы св€затьс€ с сервером GitHub. ≈сли вы используете Chrome или Firefox с установленным расширением Firebug, вы можете подробно изучить HTTP-запрос, перейд€ на вкладку Ђ—етьї или ЂNetworkї. — открытой кладкой Ђ—етьї, перейдите на сайт www.github.com, введ€ его в адресную строку, и вы должны увидеть что-то подобное:

Network

«атем на левой панели щелкните по первому пути, Ђgithub.com.ї “еперь вы должны увидеть следующее:

Headers

«аголовок запроса 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.

Response

ƒополнительные упражнени€

Ќадеюсь, такой разбор позволит вам лучше пон€ть структуру 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-адресов.)

404

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. — таким багажом знаний, следующий проект дл€ вас будет намного проще.


>