Программирование HTTP с использованием WCF - Представление дополнительных сведений
ОГЛАВЛЕНИЕ
Представление дополнительных сведений
Приложение, получающее HTTP GET, использует сведения, встроенные в URI-адрес, для определения ресурса, который должен быть отправлен в качестве ответа. Чтобы проиллюстрировать это, рассмотрим следующий набор URI-адресов:
contoso.com/artists/Flaming+Hammer/HitMe
contoso.com/artists/Northwind/Overdone
Для этого случая у корпорации Contoso имеется приложение, обслуживающее ресурсы, имеющие отношение к музыке. Можно попытаться вывести из этих примеров способ, с помощью которого имя исполнителя и название альбома сопоставляется URI-адресу:
contoso.com/artists/[artist]/[album]
Когда приложение получает сообщение HTTP GET для http://contoso.com/artists/Northwind/Overdone, оно должно вернуть ресурс, связанный с альбомом Northwind's Overdone. Понятно, что имеется шаблон URI-адреса. Он состоит из некоторой базовой информации (contoso.com/artists) и некоторых сегментов URI-адреса (или «дыр»), которые будут содержать значения, соответствующие исполнителю и альбому.
Так же распространенным приемом является внедрение информации некоторого типа в параметры строки запроса. Хотя этот формат отличается от предыдущих примеров, конечные результаты будут одинаковыми. Приведем набор «дыр» URI-адреса с параметром строки запроса:
contoso.com/artists/Flaming+Hammer?album=HitMe
contoso.com/artists/Northwind?album=Overdone
В этом случае для URI-адреса и строки запроса используется следующий синтаксис:
contoso.com/artists/[artist]?album=[album]
Транспортный протокол HTTP для представления дополнительной информации использует также расширяемый набор заголовков. Эта информация может иметь отношение к кэшированию, типу данных в сообщении, имени приложения-отправителя, длине содержимого, операционной системе размещения и многому другому. На рис. 1 показано сообщение HTTP GET (строки 1-8) и ответное сообщение (строки 9-14) с несколькими распространенными заголовками.
Рис. 1 HTTP GET Request and Response
1 GET /PictureServices/Feed.svc/picture/Pictures;Bridge.jpg HTTP/1.1
2 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-ms-application, application/vnd.ms-xpsdocument,
application/xaml+xml, application/x-ms-xbap,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash,
application/x-silverlight, */*
3 Accept-Language: en-us
4 UA-CPU: x86
5 Accept-Encoding: gzip, deflate
6 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; InfoPath.2; .NET CLR 1.1.4322;
.NET CLR 3.5.20706; .NET CLR 3.0.590; MS-RTC LM 8)
7 Host: www.cloudsamples.net
8 Proxy-Connection: Keep-Alive
9 HTTP/1.1 200 OK
10 Content-Type: image/jpeg
11 Server: Microsoft-IIS/7.0
12 X-Powered-By: ASP.NET
13 Date: Sat, 15 Sep 2007 18:57:11 GMT
14 Content-Length: 106333
Заголовок Accept в запросе HTTP GET указывает на предпочтительный для клиента формат данных. Как видно из длинного списка значений, клиент может принимать несколько типов данных (изображения, документы office, приложения Silverlight и т.д.). В отклике на HTTP GET содержатся данные, формат которых описывается значением заголовка Content-Type (image/jpeg, как указано в строке 10). Этот простой механизм позволяет отправляющему и принимающему приложению согласовывать форматы данных. Использование заголовков для согласования форматов данных является не таким выразительным средством, как грамматики языков WSDL (Web Services Description Language) и формата XSD (XML Schema Definition) веб-служб SOAP, но его вполне достаточно для работы в среде Интернета.