Универсальные идентификаторы ресурсов
В основу программирования для Интернета положено понятие универсального иден-тификйтора ресурса (URI), иногда еще называемого унифицированным указателем информационного ресурса (URL). Этот идентификатор описывает местоположение ресурса в сети. В корпорации Microsoft принято пользоваться сокращением URI при описании членов пространства имен System.Net, и поэтому в данной книге выбрано именно это сокращение для обозначения универсального идентификатора ресурса. Идентификаторы URI, без сомнения, известны каждому, кто хотя бы раз пользовался браузером для поиска информации в Интернете. По существу, это адрес информационного ресурса, который указывается в соответствующем поле окна браузера.
Ниже приведена общая форма идентификатора URI:
Протокол: // Идентмфмкационный_номер_сервера/Путь_к_файлу1 Запрос
где Протокол — это применяемый протокол, например HTTP; Идентификацион-ный_номер_сервера — конкретный сервер, например mhprof essional. com или
HerbSchildt. com; Путь_к_файлу — путь к конкретному файлу. Если же Путь_к_ файлу не указан, то получается страница, доступная на указанном сервере по умолчанию. И наконец, Запрос обозначает информацию, отправляемую на сервер. Указывать Запрос необязательно. В C# идентификаторы URI инкапсулированы в класс Uri, рассматриваемый далее в этой главе.
Основы организации доступа к Интернету
В классах, находящихся в пространстве имен System.Net, поддерживается модель взаимодействия с Интернетом по принципу запроса и ответа. При таком подходе пользовательская программа, являющаяся клиентом, запрашивает информацию у сервера, а затем переходит в состояние ожидания ответа. Например, в качестве запроса программа может отправить на сервер идентификатор URI некоторого веб-сайта. В ответ она получит гипертекстовую страницу, соответствующую указанному идентификатору URL Такой принцип запроса и ответа удобен и прост в применении, поскольку большинство деталей сетевого взаимодействия реализуются автоматически.
На вершине иерархии сетевых классов находятся классы WebRequest и WebResponse, реализующие так называемые подключаемые протоколы. Как должно быть известно большинству читателей, для передачи данных в сети применяется несколько разнотипных протоколов. К числу наиболее распространенных в Интернете относятся протокол передачи гипертекстовых файлов (HTTP), а также протокол передачи файлов (FTP). При создании идентификатора URI его префикс обозначает применяемый сетевой протокол. Например, в идентификаторе http: //www. HerbSchildt. com используется префикс http, обозначающий протокол передачи гипертекстовых файлов (HTTP).
Как упоминалось выше, классы WebRequest и WebResponse являются абстрактными, а следовательно, в них определенны в самом общем виде операции запроса и ответа, типичные для всех протоколов. От этих классов наследуют более конкретные производные классы, в которых реализуются отдельные протоколы. Эти производные классы регистрируются самостоятельно, используя для этой цели статический метод RegisterPrefix () , определенный в классе WebRequest. При создании объекта типа WebRequest автоматически используется протокол, указываемый в префиксе URI, если, конечно, он доступен. Преимущество такого принципа "подключения" протоколов заключается в том, что большая часть кода пользовательской программы остается без изменения независимо от типа применяемого протокола.
В среде выполнения .NET Runtime протоколы HTTP, HTTPS и FTP определяются автоматически. Так, если указать идентификатор URI с префиксом HTTP, то будет автоматически получен HTTP-совместимый класс, который поддерживает протокол HTTP. А если указать идентификатор URI с префиксом FTP, то будет автоматически получен FTP-совместимый класс, поддерживающий протокол FTP.
При сетевом подключении к Интернету чаще всего применяется протокол HTTP, поэтому именно он и рассматривается главным образом в этой главе. (Тем не менее аналогичные приемы распространяются и на все остальные поддерживаемые протоколы.) Протокол HTTP поддерживается в классах HttpWebRequest и HttpWebResponse. Эти классы наследуют от классов WebRequest и WebResponse, а кроме того, имеют собственные дополнительные члены, применимые непосредственно к протоколу HTTP.
Читать дальше