RESTful веб-сервисы

Question

Я новичок в веб-сервисах RESTful.Мы выбираем маршрут REST для создания наших общедоступных веб-служб, которые будут использоваться нашими клиентами. И у меня возникло несколько вопросов.

Существуют ли какие-либо ограничения в отношении чисто веб-служб REST?и если да, то о таких ограничениях позаботится гибридный веб-сервис REST?

Я думаю об использовании SSL + кода аутентификации хэш-сообщения (HMAC) в заголовке авторизации для обеспечения безопасности наряду с фильтрацией на основе IP.что вы, ребята, думаете об этом?

Есть ли хорошие инструменты на стороне клиента для тестирования?В настоящее время я использую следующее http://code.google.com/p/rest-client/

А как насчет какого-либо инструмента генерации кода на стороне клиента?

Следующие ссылки являются моим источником информации.

http://msdn.microsoft.com/en-us/library/dd203052.aspx

http://blogs.msdn.com/b/endpoint/archive/2010/01/07/getting-started-with-wcf-webhttp-services-in-net-4.aspx

Answer 1

Первое, что нужно иметь в виду, это то, что служба REST не должна иметь состояния, что сильно отличается по сравнению с интерфейсом службы типа SOAP / RPC.Использование методологии REST требует от вас переосмысления того, как вы хотите, чтобы ваши клиенты взаимодействовали со службой, разбивая взаимодействия на четкие и краткие вызовы методов.

REST
+ Легкие сообщения, очень небольшие накладные расходы (кроме самого XML)
+ Легко читаемые результаты, легко тестируются с помощью веб-браузера
+ Простота реализации
-Более простой интерфейс, свободная проверка типов

SOAP
+ Более жесткий, со строгим определением контракта
+ Множество доступных инструментов разработки.

Просматривая документацию MSDN WCF, поддержка WCF SOAP была интегрирована с самого начала, а поддержка REST - недавно добавленной функцией.Мне самому трудно найти документацию для аутентификации / безопасности для сервисов REST, так как большая часть документации направлена ​​на SOAP.

Инструменты генерации на стороне клиента: я не встречал ни одного сервиса REST как RESTне определяет сервисный контракт, как SOAP.WADL - это попытка сделать это для служб REST.http://en.wikipedia.org/wiki/Web_Application_Description_Language http://wadl.codeplex.com/

Мне интересно читать больше ответов, касающихся аутентификации и безопасности, так как я сам разбираюсь в этом.

Answer 2

Это хорошая отправная точка веб-службы REST WCF:

Конечные точки REST / SOAP для службы WCF

(Кстати, Stackoverflow имеет хороший тип REST:urls.) Вы можете протестировать службу REST только с помощью веб-браузера (перейдите по ссылке и получите XML или JSON).Fiddler также хороший инструмент и FireBug-плагин для FireFox.Я обычно делаю тонкий интерфейс с сервисным интерфейсом и отдельный (проверенный модулем) логический проект.

Для аутентификации я сначала сгенерирую Guid и временную метку.Затем на основе этих хэшей (.NET поддерживает SHA256 и SHA512).Guid может быть сохранен на сервере (таблица базы данных), чтобы отобразить в нем какой-то конкретный числовой идентификатор.Затем вы можете создать URL для отдыха, например:

/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y 

и просто отключить проверку хешей и временных меток в среде разработки (например, с помощью AOP).С отметкой времени я бы проверил, что штамп находится между 15 минутами назад и вперед (= должно быть достаточно, чтобы предотвратить атаки).

Будет ли ваш сервис видимым для широкой публики / интернета и является ли ваш клиент клиентом jQuery или Silverlight?Тогда у вас все еще есть проблема: вы не хотите включать секретный ключ в код программного обеспечения клиента.

Таким образом, вам нужно сгенерировать хеш на сервере и какой-нибудь cookie для хранения сеанса клиента.(Это можно сделать, например, с помощью отдельной страницы входа / приложения в папке с другим файлом конфигурации.) Я помню, что эта книга действительно имела что-то по теме:

Если выЕсли вы хотите включить HttpContext при использовании WCF, вам нужно установить <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> в <system.serviceModel>.Затем вы можете проверить текущую идентификационную информацию пользователя с HttpContext.Current.User.Identity.Name.

. Однако, если вы хотите сделать чистую службу REST, вы не используете куки, но базовую аутентификацию HTTP в сочетании с SSL / TLS для каждого вызова.

Я думаю, что легко сделать клиента с помощью только LINQ2Xml или jQuery, поэтому, возможно, генерация клиента не нужна.

Или вы можете также иметь и интерфейс SOAP и REST, ииспользуйте сервисную ссылку, чтобы сделать клиента.

Answer 3

Следует иметь в виду, что REST можно использовать как философию (все должно быть доступно по чистому URL, без скрытых строк) или как догма (вы должны использовать PUT и DELETE, даже если это означаетмного трудностей в будущем).

Акцент делается на упрощение - например, использование простых типов данных для параметров вместо структурированных скоплений, или удлиняющий интерфейс по излишним причинам (например, буксировка гигантской страницы "title" в URL)без использования заголовков, которые не являются общеизвестными и де-факто стандартными.

Таким образом, вы можете создать совершенно RESTful-интерфейс, используя только GET, и сохранить удобство использования и тестируемость из веб-браузеров.Вы также можете использовать любые стандартные методы аутентификации или несколько из них для резервирования в зависимости от вашей целевой аудитории.Если вы создаете приложение для запуска в корпоративной сети со стандартными учетными данными и токенами, вы можете продолжать использовать это.Если вы делаете что-то для очень общего доступа, вы можете использовать комбинацию аргументов GET и / или файлов cookie - ваши URL-адреса будут чистыми для 99,99% пользователей.

Вы можете даже обслуживать как JSON, так и XML (например, Googleкарты, например) и по-прежнему быть RESTfull, но вы не можете сделать полномасштабное SOAP (сложные типы ввода и т. д.).Вы можете сделать ограниченный SOAP - простые типы для запросов, всегда выражаемые в виде аргументов GET, люди по-прежнему получают WSDL для документации.

Надеюсь, это рисует достаточно гибкую картину - способ мышления выше любой строгой догмы.