HTTP — это протокол, используемый для доставки наших веб-приложений конечному пользователю; кроме того, в каждой интеграции приложений на основе REST это транспортный протокол для обмена данных между различными компонентами или услугами.
Учитывая эту вездесущность, знание спецификации HTTP наизусть и функций, уже реализованных в протоколе, может быть только полезным. Я удивлен, что в Интернете полно теоретического материала и пояснений к стандарту, но нет упражнений REST или HTTP, которые бы стимулировали практиковать его.
Итак, в прошлую пятницу мы собрали некоторые ресурсы и установили HTTP в качестве цели нашего книжного клуба. Как сказал Деминг, ничто не заменит знания.
Поиск материала
Чтение документов спецификации HTTP было бы очень скучным в групповой настройке. кроме того, RFC дистиллированы и иногда изолированы друг от друга (HTTP 1.0 против 1.1). Несмотря на то, что они, безусловно, являются хорошим справочным материалом, конкретные учебные материалы выиграют в эффективности.
Я выбрал « Кэширование Fabien Potencier» на краевой презентации в качестве основного руководства. В этой слайд-колоде представлены функции кэширования HTTP, используемые серверами, клиентами и кешами на пути между ними; Это оптимальный повод заранее рассмотреть основные понятия HTTP, такие как методы, код ответа и заголовки.
Переполнение стека также является очень утонченным источником теоретических объяснений: когда вы сомневаетесь в том, как использовать конкретный заголовок или в чем разница между Expires и Cache-Control, он может найти ответ для вас. Этот ответ возник из экспертной оценки и был получен после многих лет распространения протокола, в отличие от оригинальных RFC. Это определенно побьет W3schools .
инструменты
Теория полезна, но практика совершенна (и она также лучше удерживается в нашем мозгу). Стандартным инструментом для выполнения HTTP-запросов является curl:
curl -v -X POST -H 'Accept: application/json' -d 'param=value1&another=value2' http://example.com/resource
Вы можете начать с нацеливания на собственное приложение, чтобы увидеть заголовки, которые вы явно задаете в ответах, и заголовки, добавленные вашим контейнером (Apache, Tomcat или инфраструктура). Например, это тестовый ресурс, который мы используем для тестирования наших HTTP-клиентов:
$ curl -v -X GET http://www.onebip.com/smsctest/answer.php
* About to connect() to www.onebip.com port 80 (#0)
* Trying 54.246.143.10... connected
> GET /smsctest/answer.php HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: www.onebip.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 14 Nov 2013 20:44:54 GMT
< Server: Apache
< X-Onebip-Node: ws-b-46.production.onebip.com
< Vary: Accept-Encoding
< Content-Length: 2
< Content-Type: text/html; charset=utf-8
< Cache-control: private
< Set-Cookie: SERVERID=01-FUSF5JEJKQ68M; path=/
< Via: 1.1 www.onebip.com
< Connection: close
<
* Closing connection #0
42
Чтобы поэкспериментировать с кэшированием, мы использовали вместо этого ссылки на скачивание ISO debian.org. Они имеют:
- перенаправляет и соответствующие коды состояния (302, 304).
- заголовки кэша на основе условного поведения (Last-Modified, Etag)
Большие размеры файлов, такие как файл .iso, позволяют понять, почему GET является наиболее оптимизированной операцией в сети.
Делиться знаниями
Я немного узнал о проблемах системных администраторов, связанных с настройкой кэшей и HTTP-серверов. Вместо этого разработчики поделились своим использованием HTTP-заголовков на стороне сервера для запуска определенных вариантов поведения — от выбора классического макета пользователем-агентом до согласования содержимого на основе Accept, Accept-Language и Accept-Encoding.
Это был также хороший повод для определения обязанностей, чтобы разработчики и оперативники не наступали друг на друга. Например:
- разработчики приложений определяют значение заголовков Cache-Control, чтобы определить, что кэшируется, а что нет.
- Системные администраторы включают серверные кэши, такие как Apache mod_cache. Кэширование полных ответов не зависит от приложения и не затрагивает код, написанный на вашем любимом языке программирования.
- Вместо этого клиентские кэши должны использоваться клиентом явно. В среде SOA кажется, что на стороне сервера достаточно.
Объем того, что вы можете исследовать за один сеанс, ограничен пропускной способностью нашего ума и выделенным временем (минимум из двух). Не преувеличивай.
Выводы
Я предполагаю, как и использование, что вы веб-разработчик, работающий с веб-сервисами RESTful внутри и на границе приложения. Знание HTTP — это базовые знания: это строительный блок, сравнимый с процессором и памятью, или для лучшего сравнения TCP. Будучи стандартом старше 20 лет, который претерпел некоторые изменения, он также является стабильным знанием, что означает, что работа с ним будет длиться гораздо дольше, чем игра с новой структурой или инструментом.
Однако не стоит останавливаться на достигнутом: над Httpbis ведется работа …