2.5 RESTful-сервисы для распределенных инфраструктур
Рассмотрим возможность построения сервисов распределенной инфраструктуры как RESTful-веб-сервисов на примере Simple Shopping Service из WSRF Primer [2-26]. Этот пример был выбран потому, что он используется для иллюстрации использования WSRF в официальной документации стандарта. Для удобства сравнения документы будем представлять в виде XML по той же схеме, что и в [2-26].
Сервис представляет собой простой сервис магазина, позволяющий пользователю создавать, получать и обновлять содержимое корзины покупок через операции «забрать» и «положить». Сервис магазина также предоставляет доступ к каталогу продуктов с возможностью поиска. Описание реализации этого сервиса выходит за рамки настоящего отчета. Код продукта из каталога и количество используются для формирования первоначальной корзины покупок, в которую затем могут быть добавлены новые продукты. Кроме того, определяется операция оформления покупки, которая взаимодействует с сервисом оплаты и переводит содержимое корзины в содержимое нового ресурса – заказа, а корзина покупок уничтожается.
2.6 Простые манипуляций с ресурсами 2.6.1 Создание ресурсов
Для создания корзины покупок клиент посылает HTTP-запрос, используя метод POST по URI коллекции корзин, https://example.com/v1/shoppingcarts/:
POST /v1/shopping-carts/ HTTP/1.1
Content-Type: application/xml
Cat-A2004-87968556
1
Ответ сервиса содержит информацию об URI созданной корзины:
HTTP/1.1 201 Created
Location: https://example.com/v1/shopping-carts/1234
2.6.2 Свойства ресурсов
Клиент получает информацию о текущем содержимом корзины. Для этого он посылает HTTP-запрос, используя метод GET по URI корзины, полученному при создании. При этом клиент использует заголовок Accept для указания формата, в котором ожидает получить содержимое корзины:
GET /v1/shopping-carts/1234 HTTP/1.1
Accept: application/xml
Клиент мог бы указать в заголовке Accept другой тип, например, application/json или text/html; в последнем случае сервер мог бы вернуть представление ресурса-корзины в виде HTML-документа. Ответ сервера с содержимым корзины:
HTTP/1.1 200 OK
Content-Type: application/xml
Cat-A2004-87968556 Garden String - 150m 1 1.59
Тело данного ответа имеет важное отличие от [2-26]: элемент корзины содержит атрибут href, указывающий URI ресурса, соответствующего определенному объекту, находящемуся в корзине. Это позволяет рассматривать корзину как самостоятельную коллекцию ресурсов – экземпляров объектов, находящихся в корзине. Такой подход дает возможность манипулировать составными частями ресурса без использования сложных ResourceProperty документов [2-49]. Например, для изменения количества предметов данного типа клиенту достаточно послать запрос
PUT /v1/shopping-carts/1234/567 HTTP/1.1
Content-Type: application/xml
2
Это существенно проще операции изменения ResourceProperty документа с последующим анализом изменений сервисом, как это происходит при использовании WSRF. Ответ сервиса на запрос об изменениях содержит только статус-код успешного завершения операции:
HTTP/1.1 204 No Content
Для сравнения, та же самая операция изменения количества предметов для WSRF-сервиса потребовала бы следующего запроса:
POST /SimpleShoppingService
Host : example . com
Content - Type : application / soap + xml
< SOAP - ENV : Envelope
xmlns : SOAP - ENV =" http :// schemas . xmlsoap . org / soap / envelope /"
xmlns : wsa =" http :// www . w3 . org /2005/08/ addressing "
xmlns : wsrf - rp =" http :// docs . oasis - open . org / wsrf / rp -2"
xmlns : rpimpl =" http :// example . com /SimpleShoppingService/ schema " >
< SOAP - ENV : Header >
< wsa : MessageID > uuid :7 a6e10d2 -0 e15 -459 e - b553 -4 cef96b5ebed
< wsa : Action >
http :// docs . oasis - open . org / wsrf / rpw -2/PutResourceProp ertyDocument/
PutResourcePropertyDocument
< wsa : To > http :// example . com / SimpleShoppingService
< wsa : From >
< wsa : Address >
http :// www . w3 . org /2005/08/ addressing / anonymous
< rpimpl : CartId wsa : IsReferenceParameter=" true " >1234
< rpimpl : ItemId wsa : IsReferenceParameter=" true " >567
< SOAP - ENV : Body >
< wsrf - rp : PutResourcePropertyDocument >
< ssc : Quantity >2
Далее для краткости примеры WSRF-запросов будут приводиться в упрощенном виде, без указания всех заголовков и пространств имен. Опущенные части полностью соответствуют использованным в данном приме- ре.
Спецификация WSRF предусматривает возможность выбора подмножества свойств ресурса, удовлетворяющих определенным критериям путем запроса QueryResourceProperties. Например, следующий WSRF-запрос может быть использован для того, чтобы выбрать только кодов продуктов товаров, находящихся в корзине:
...
< SOAP - ENV : Header >
...
< wsa : Action >
http :// docs . oasis - open . org / wsrf / rpw -2/QueryResourceProperties/
QueryResourcePropertiesRequest
...
< SOAP - ENV : Body >
< wsrf - rp : QueryResourceProperties >
< wsrf - rp : QueryExpression
xmlns : xsi =" http :// www . w3 . org /2001/ XMLSchema - instance "
Dialect =" http :// www . w3 . org / TR /1999/ REC - xpath -19991116"
xsi : type =" wsrf - rp : QueryExpressionType" >
//*[ local - name ()=" ProductCode "]
...
Для получения аналогичной функциональности в RESTful-грид-сервисах предлагается использовать запросы с HTTP-методом GET по адресу соответствующих ресурсов, содержащие дополнительную строку запроса в компоненте query URI ресурса. Синтаксис URI предусматривает следующую структуру идентификатора [2-24]:
схема:иерархический компонент?запрос#фрагмент
Для замены запросов аналогичных QueryResourceProperties и GetResourceProperty/GetMultipleResourceProperties предлагается использовать компоненты «запрос» и «фрагмент» URI, указывая язык запроса в компоненте «фрагмент», и сам запрос в соответствующем компоненте. Приведем два примера использования такого подхода. Чтобы не загромождать запись, URI приводятся в текстовом виде без использования «процентного кодирования» зарезервированных символов.
Запрос части свойств:
https://example.com/v1/shopping-carts/1234?//*[local-name()="ProductCode"]#XQuery
Поле «фрагмент» указывает на использование языка XQuery; сам запрос указывает, что требуется вернуть только атрибуты ProductCode ресурсов, то есть только коды продуктов покупок, находящихся в корзине.
Этот пример полностью эквивалентен WSRF-варианту, приведенному выше.
Запрос ресурсов, удовлетворяющих критериям.
https://example.com/v1/shopping-carts/1234?Quantity < 10 AND ProductPrice > 1.5#SQL
Поле «фрагмент» указывает на использование языка запросов SQL; сам запрос указывает, что требуется вернуть ресурсы, для которых атрибут Quantity имеет значение менее 10 и атрибут ProductPrice более 1.5, то есть те покупки, цена которых более 1.5 и количество в корзине менее 10.
Такой подход к использованию URI ресурсов для запроса частей свойств или ресурсов, удовлетворяющих определенным критериям, является более гибким, чем подход из WSRF, так как не ограничивает выбор языка запросов, что позволяет использовать наиболее подходящие к контексту языки.
Спецификация WSRF предусматривает возможность выбора части свойств ресурса, удовлетворяющих определенным критериям, путем запроса QueryResourceProperties. Для получения аналогичной функциональности в RESTful-гридсервисах рекомендуется использовать запросы с HTTP-методом GET по адресу соответствующих ресурсов, содержащие дополнительную строку запроса в компоненте query URI ресурса (RFC 3986). Используемый язык запроса может быть указан в компоненте fragment URI ресурса.
2.6.3 Индикация ошибок
Спецификация WSRF предусматривает также универсальный подход к передаче и обработке ошибочных состояний. RESTful-грид-сервис использует для этой цели стандартные коды статусов HTTP с документами, поясняющими детали произошедшей ошибки. Согласно WS-BaseFaults [2-27], каждая информация об ошибке является производной от общего класса ошибок. Кроме того, для распространенных ошибок предусмотрен набор стандартных классов ошибок. RESTful-грид-сервисы должны использовать вместо соответствующих классов ошибок коды состояния HTTP со значениями 4xx и 5xx. Ошибки, не попадающие ни в один из стандартных классов, должны иметь код состояния 400 Bad Request, при этом тело ответа обязательно должно содержать представление ресурса, описывающего произошедшую ошибку. Вместо стандартной ошибки ResourceUnknownFault спецификации WS-BaseFaults следует использовать код состояния 404 Not Found, а вместо стандартной ошибки ResourceUnavailableFault той же спецификации – код состояния 403 Forbidden или 401 Unauthorized в зависимости от причины недоступности ресурса.
Для RESTful-грид-сервисов предлагается следующая интерпретация прочих стандартных кодов состояния HTTP в качестве стандартных ошибок.
405 Method Not Allowed. Используется в том случае, если запрашиваемая операция над ресурсом не предусматривается данным сервисом. Например, сервис должен возвращать данный код при попытке изменения методом PUT ресурса, доступного только для чтения.
406 Not Acceptable. Применяется для согласования представления ресурса с клиентом в случае, если клиент запросил представление ресурса в формате, который не может быть предоставлен данным сервисом.
409 Conflict. Используется, когда выполнение запрошенной операции может привести сервис в невозможное или несовместимое состояние, например, при попытке создать ресурс с идентификатором, который уже востребован другим ресурсом.
410 Gone. Этот ресурс более недоступен через данный сервис. Новый способ доступа к ресурсу неизвестен.
415 Unsupported Media Type. Запрос к серверу содержал представление ресурса в формате, который не может быть обработан данным сервисом.
503 Service Unavailable. Данный запрос не может быть обслужен сервисом в настоящее время. Ответ с таким кодом состояния может содержать заголовок Retry-After, при наличии этого заголовка клиент может повторить попытку такого же запроса в указанное время.
Для детализации причины, вызвавшей ошибку, ответ может содержать заголовок Location с URI, указывающим на ресурс, являющийся причиной ошибки. В тех случаях, когда причиной ошибки является ресурс, к которому производилось обращение, в качестве причины ошибок можно использовать URI в формате URN (RFC 2141). В частности, далее определяются URI для некоторых стандартных причин ошибок в формате URN в пространстве имен X-RESTful-Grid.
Таким образом, RESTful-грид-сервисы предоставляют разработчику более разнообразный набор стандартных методов индикации ошибок, чем WSRF.
Приведем пример ошибочного запроса на изменение количества товаров в корзине и ответ сервиса на этот запрос, содержащий информацию об ошибке (ответ сервиса выделен курсивом):
PUT / v1 / shopping - carts /1234/567 HTTP /1.1
Host : example . com
Content - Type : application / xml
< ssc : Quantity > -5
HTTP/1.1 400 Bad Request
Content-Type: text/plain
Pragma: no-cache
Cache-Control: no-cache
Location: urn:example.com:invalid-product-quantity
Product quantity cannot be negative.
2.6.4 Цикл существования ресурсов
Рассмотрим методы контроля времени жизни ресурса, а также способы уничтожения ресурсов. Для контроля времени жизни ресурсов и управления им предлагается использовать заголовки протокола HTTP. Параметру CurrentTime спецификации WSRF соответствует стандартный заголовок Date.
Для обозначения времени жизни ресурса предлагается использовать нестандартный заголовок Termination-Time, спецификация которого в расширенной форме Бэкуса-Наура [2-28] приводится ниже:
Termination - Time = " Termination - Time " ": " rfc1123 - date
rfc1123 - date = wkday " , " date " " time " GMT "
wkday = " Mon " / " Tue " / " Wed " / " Thu " / " Fri " / " Sat " / " Sun "
date = 2* DIGIT " " month " " 4* DIGIT
month = " Jan " / " Feb " / " Mar " / " Apr " / " May " / " Jun " /
" Jul " / " Aug " / " Sep " / " Oct " / " Nov " / " Dec "
time
= 2* DIGIT ":" 2* DIGIT ":" 2* DIGIT
Поле date содержит дату в формате день месяц год; поле time содержит время, в диапазоне 00:00:00 — 23:59:59.
Необходимость использования отдельного заголовка для указания времени жизни вызвана тем, что другие близкие по смыслу стандартные заголовки имеют интерпретацию, связанную с конкретным представлением ресурса, а не ресурсом в целом. Так, например, заголовок Expires имеет стандартную интерпретацию как актуальность/время жизни данного представления, и, поэтому, не может использоваться для указания времени жизни ресурса.
Заголовок Termination-Time является опциональным, и может присутствовать как в запросе, так и в ответе (рис. 2.5).
Рисунок 2.5 - Диаграммы работы с временем жизни ресурса во время запроса
представления ресурса, запроса на изменение ресурса, а так же запроса на
изменение времени жизни без изменения самого ресурса.
Наличие заголовка Termination-Time в запросе используется для изменения времени жизни ресурса. В случае такой возможности грид-сервис должен выполнить действия, соответствующие запросу, и изменить время жизни ресурса. В ответе на запрос должен присутствовать заголовок Termination-Time, содержащий новое время жизни ресурса. В случае, если указанное изменение времени жизни невозможно или не поддерживается для данного ресурса, грид-сервис не выполнит действие, соответствующее запросу, и вернет ответ с кодом состояния 409, содержащий заголовок Location: urn:X-RESTful-Grid:invalid-TerminationTime.
Наличие заголовка Termination-Time в ответе грид-сервиса указывает, что данный ресурс может быть автоматически уничтожен сервисом в указанный момент, однако не гарантирует уничтожения ресурса. Отсутствие заголовка TerminationTime в ответе грид-сервиса означает, что время жизни ресурса не определено явно и клиент не должен делать предположения о времени жизни ресурса.
Для изменения времени жизни ресурса без совершения каких-либо операций с ресурсом предлагается использовать расширенное указание Pragma: only-termination-time. Чтобы изменить время жизни ресурса не совершая операций, клиент отправляет серверу запрос методом PUT, в котором присутствует заголовок Pragma: only-termination-time и желаемое значение времени жизни ресурса в заголовке Termination-Time, но отсутствует представление ресурса. Запрос, содержащий представление ресурса и такой набор заголовков считается ошибочным, сервер должен вернуть ответ с кодом состояния 400 и заголовком Location: urn:X-REST- ful-Grid:invalid-pragma-combination.
2.6.5 Безопасность и идемпотентность методов
Однократное создание ресурсов. Для традиционных WSRF-веб-сервисов протокол HTTP выполняет только транспортные функции, при их реализации применяются исключительно запросы с методом POST, не являющиеся идемпотентными или безопасными. Для RESTful-грид-сервисов используются многие другие методы протокола HTTP, поэтому особое внимание необходимо уделять требованиям безопасности и идемпотентности методов [2-8], а именно.
Действия, выполняемые методами GET и HEAD, должны заключаться только в собственно возвращении представления ресурсов и не должны иметь побочных эффектов.
Действия, выполняемые методами PUT и DELETE, должны быть идемпотентными, то есть побочные эффекты, вызываемые запросом с таким методом, должны быть одинаковыми для любого количества повторений одного и того же запроса.
Выполнение требований идемпотентности позволяет повысить надежность работы клиентских приложений через плохие каналы связи, так как в случае отсутствия ответа сервера клиент может просто повторить идемпотентный запрос еще раз.
Метод POST протокола HTTP, используемый для создания новых ресурсов, не имеет требования идемпотентности, так как она не может быть обеспечена в рамках спецификации HTTP 1.1, однако при реализации RESTful-грид-сервисов необходима идемпотентность всех методов, включая и те, что используются для создания новых ресурсов.
Одна из попыток обеспечения идемпотентности метода POST осуществляется в проекте спецификации Post Once Exactly (POE) [2-29], однако такая черновая спецификация не предусматривает способа получения клиентом ответа сервиса, содержащего результаты выполнения операции, а данные результаты в случае RESTful-грид-сервиса содержат URI созданного ресурса. Поэтому предлагается расширить спецификацию [2-29] следующим образом: в том случае, если сервис получает повторный запрос клиента с методом POST, соответствующий спецификации POE, ответ сервиса должен быть идентичным ответу на первый запрос, за исключением кода ответа 405 и дополнительного заголовка Allow, необходимого в ответах с кодом 405. Такая реализация позволяет обеспечить идемпотентность запросов с методом POST без потери первоначального ответа сервиса.
Для реализаций грид-сервисов, в которых использование расширений POE нежелательно, рекомендуется отказаться от использования метода POST для создания новых ресурсов и применять для этих целей исключительно метод PUT, возложив ответственность за создание уникальных идентификаторов ресурсов на клиента.
Альтернативным решением проблемы создания ресурсов идемпотентными методами является генерация идентификаторов ресурсов на стороне клиентов следуя правилам, описанным в интерфейсе прикладного программирования сервиса, и использование метода PUT для создания ресурсов. При использовании этого подхода возникает проблема гарантии уникальности идентификатора создаваемого ресурса для исключения возможности случайного изменения уже существующего ресурса. Однако, эта проблема актуальна не во всех случаях, и может быть решена с использованием дополнительных стандартных заголовков и алгоритма, описываемого ниже. При создании нового ресурса методом PUT, клиент должен использовать заголовок If-None-Match со специальным значением «*». Учитывая семантику этого заголовка и данного специального значения, определенную в [2-8], сервис в этом должен выполнить такой запрос только в том случае, если адресуемый ресурс ранее не существовал. Если же ресурс уже существовал, то сервис возвращает ошибку с кодом 412 Precondition Failed. В этом случае, клиент может сгенерировать новый идентификатор ресурса и повторить попытку. Используя такой метод создания ресурсов, можно дополнительно сократить повторную пересылку представлений при помощи метода условного продолжения/прерывания запросов Expect/Continue протокола HTTP 1.1. Суть этого метода заключается в следующем: при отправке заголовков запроса клиент указывает заголовок Expect: 100-continue, и, закончив передачу заголовков, не начинает передачу представления ресурса. Сервер, получив запрос, содержащий такой заголовок, должен не дожидаясь получения представления ресурса ответить специальным кодом состояния 100 Continue, если из информации, полученной сервисом на данный момент следует, что запрос может быть выполнен, либо вернуть код состояния с ошибкой. В случае, если сервер вернул код состояния 100, клиент посылает представление создаваемого ресурса. В случае ошибки клиент может повторить попытку, используя новый идентификатор ресурса. Такой метод создания ресурсов схематично изображен на рис. 2.6.
Рисунок 2.6 - Последовательность запросов при создании нового ресурса с использованием метода PUT, в случае неудачи первой попытки создания
идентификатора ресурса и протокола HTTP/1.1.
2.6.6 Аутентификация запросов
Аутентификация — это проверка предъявленного идентификатора на принадлежность субъекту доступа [2-30]. С точки зрения грида, задача аутентификации заключается в проверке того, является ли сторона, посылающая запросы, той сущностью (то есть тем пользователем или сервисом), за которую она себя выдает. Следует отличать аутентификацию от авторизации: проверки наличия прав у субъекта доступа на выполнение запрашиваемых действий.
Протокол HTTP имеет стандартный механизм аутентификации пользователей, использующий заголовки Authorization и WWW-Authenticate [2-8]. Начальная аутентификация через этот механизм производится стандартной последовательностью запрос-вопрос-ответ (request-challenge-response).
Клиент посылает запрос, требующий аутентификации, сервису, и получает ответ 401 Unauthenticated с заголовком WWW-Authenticate, содержащим по крайней мере один вопрос (возможно, содержащий дополнительные параметры), ответ на который клиент должен сообщить серверу в заголовке WWW-Authenticate повторив запрос (рис. 2.7 содержит пример обмена сообщениями по этой схеме с использованием схемы аутентификации Basic, описанной далее). При последующих запросах клиент может заблаговременно передавать заголовок Authorization в запросах, используя для вычисления ответов информацию исходного вопроса.
Для использования с этими заголовками определяется две стандартных схемы аутентификации, Basic и Digest, подробно описываемые в [2-31]. Эти схемы используют в качестве параметров доступа имя пользователя и пароль. В случае использования схемы Basic (рис. 2.7), в ответ на запрос, требующий аутентификации пользователя, сервис возвращает код ошибки 401 и дополнительный заголовок WWW-Authenticate, содержащий название используемой схемы аутентификации (Basic) и используемое пространство аутентификации (realm). При повторении запроса к этому же ресурсу, клиент должен указать в запросе дополнительный заголовок Authorization, содержащий название используемой схемы аутентификации (Basic), а так же имя и пароль пользователя, записанные через символ «:» с последующим кодированием строки транспортной кодировкой Base64 [2-32]. В примере на рисунке 2.7 таким способом закодированы имя пользователя «bar» и пароль «qux». Таким образом, данные о параметрах аутентификации передаются в форме, позволяющей перехватить их для дальнейшего использования злоумышленниками, поэтому использовать эту схему рекомендуется только поверх защищенных соединений, например с использованием протокола HTTPS (HTTP через TLS).
Рисунок 2.7 - Первичный обмен сообщениями между клиентом и сервером при использовании аутентификации по схеме Basic.
Схема Digest использует более сложный метод защиты, с каждым запросом передается результат вычисления некоторой криптографической функции от имени пользователя, пароля, параметров запроса, дополнительных случайных величин, а так же последовательного номера запроса. Это предотвращает возможность повторного использования «подслушанного» заголовка Authorization злоумышленником и позволяет использовать эту схему на каналах связи без дополнительной криптографической защиты. Кроме того, это позволяет хранить на сервисе результат вычисления некоторой криптографической функции от имени пользователя, пароля и пространства аутентификации вместо имени и пароля пользователя.
Аутентификация с использованием заголовков Authorization/WWW-Authenticate предусматривает возможность использования любых расширенных механизмов аутентификации. Например, помимо стандартных схем определенных в [2-32], опубликована схема аутентификации Atom Authentication [2-33], переносящая параметры сообщений Web Services UserName Token Profile (WSSE) [2-34] внутрь авторизационного заголовка. Сообщения WSSE используют аналогичную Digest методику формирования параметров аутентификации, используя несколько иные принципы построения пространства аутентификации и другие хеширующие функции.
С точки зрения грид-сервисов, у всех перечисленных выше схем при- сутствует недостаток: в качестве аутентификационных данных используется имя пользователя и общий секрет. Это означает, что для использования в масштабах грида необходимо решать задачу распространения и синхронизации секретов пользователей между всеми грид-сервисами. Кроме того, администраторы ресурсов, аутентификация на которых осуществляется при помощи схем Basic, WSSE или Digest, автоматически получают техническую возможность доступа к любым другим сервисам от имени пользователя (для схемы Basic), или к сервисам, находящимся в том же пространстве аутентификации (realm) в случае использования схем Digest и WSSE. Это приводит к тому, что практическое использование этих схем в гриде становится неприемлемым.
Для грид-систем традиционным решением для аутентификации является использование сертификатов X.509 с реализацией инфраструктуры публичных ключей [2-35], включающей в себя систему удостоверяющих центров выдачи сертификатов и гарантирующей подлинность информации, содержащейся в сертификате. Далее такие сертификаты могут использоваться для установления соединений по протоколу TLS [2-36] с взаимной верификацией участников обмена данными и опциональным шифрованием передаваемой информации. При этом для шифрования передаваемых данных используется какой-либо алгоритм шифрования с симметричным ключом, выбираемым во время установления соединения. Другими преимуществом использования сертификатов является возможность использования прокси-сертификатов X.509 [2-37] для реализации однократного входа в грид, частичной передачи прав и передачи дополнительной авторизационной информации.
Большинство уже существующих грид-сервисов, как построенных на протоколах WSRF/OGSA, так и использующих GSI из Globus Toolkit уже используют клиентские сертификаты X.509 и прокси-сертификаты для аутентификации пользователей, поэтому аутентификация пользователей RESTful-грид-сервисов при помощи клиентских сертификатов X.509 или прокси-сертификатов является логичным шагом.
Таким образом, для обеспечения доступа с аутентификацией к RESTful-грид-сервисам рекомендуется использовать доступ исключительно по протоколу HTTPS [2-38] с обязательной взаимной верификацией участников на этапе установки TLS-сессии по сертификатам X.509 или прокси-сертификатам. Гарантией аутентификации в этом случае является подлинность всех используемых сертификатов в рамках установленной в данном грид инфраструктуры публичных ключей.
2.6.7 Контроль целостности передачи информации
Еще одним важным аспектом при реализации грид-сервисов является контроль за целостностью информации при обмене данными между сервисом и клиентом. Для этого предлагается использовать следующие дополнительные требования к реализациям грид-сервисов и клиентов.
Все ответы грид-сервисов, содержащие представления ресурсов, должны иметь заголовок Content-Length.
Все ответы грид-сервисов, содержащие заголовок Content-Length, отличный от 0, должны также иметь заголовок Content-MD5.
Клиент должен проверять соответствие заголовков Content-Length и Content-MD5 при их наличии полученному представлению ресурса. Отсутствие необходимых заголовков должно быть интерпретировано как ошибка.
В запросах клиентов рекомендуется использовать заголовки Content-Length и Content-Type, правила использования этих заголовков и интерпретации их сервисом аналогичны правилам для заголовков ответов сервиса.
Приведенные в настоящем отчете подходы к реализации грид-сервисов с использованием архитектуры REST позволяют получить большую часть функциональности, доступной при традиционной реализации грид-сервисов как WSRF-сервисов. Описаны процедуры получения представления ресурсов, управления циклом существования ресурсов, способы индикации ошибок.
С одной стороны, RESTful-грид-сервисы не имеют четкой стандартизации части функциональности, аналогичной утвержденной для WSRF-сервисов: нет единого подхода к запросам части свойств ресурсов, а также не определен стандартный протокол для организации сервисных групп. Это является платой за полную свободу формата представления ресурсов, так как произвольное представление ресурсов может иметь любую структуру, в том числе отличную от стандартного подхода к представлению ресурса в виде набора его свойств.
Например, для RESTful-грид-сервиса представлением ресурса может быть изображение или какой-либо другой объект, который не имеет эффективного представления в текстовом виде, пригодного для использования внутри набора свойств XML. Помимо этого, построение грид-сервисов с использованием архитектуры REST имеет ряд других преимуществ: простота реализации как клиента к такому сервису, так и самого сервиса, отсутствие зависимости от средств автоматической генерации программного кода, возможность использования произвольных представлений ресурсов, а также большая устойчивость к плохим каналам связи за счет идемпотентности всех операций, которую не может обеспечить спецификация WSRF в силу своего устройства.
|
