использование asp.net mvc для конечной точки на основе REST

Question

Я смотрю на использование ASP.Net MVC в качестве платформы для службы на основе REST. Я знаю, что WCF имеет встроенную поддержку служб REST; Тем не менее, я смотрю на возвращение нескольких типов данных в зависимости от запроса.

Я бы хотел, чтобы клиент запросил тип контента. Поэтому, если они отправят, например, text / html, я бы отобразил свою модель в Html, если они запросят text / xml, она вернет xml. Мы могли бы также сделать JSON.

Кто-нибудь видит какие-либо проблемы с этим?

Неиспользование WCF может увеличить сложность клиента при вызове службы, поскольку он не сможет автоматически сгенерировать прокси; однако в моем случае клиенты будут либо браузером, запрашивающим html, либо клиентскими библиотеками java, обрабатывающими xml.

Поскольку WCF не использовался, нам нужно защитить сервис; Тем не менее, я думаю, что мы можем сделать это с помощью проверки подлинности форм.

Преимущество этого состоит в том, что независимо от того, какой тип данных запрашивает клиент, все они проходят через одни и те же контроллеры / модели и т. Д. *

Answer 1

Решение Haack, безусловно, не лучший способ сделать это, хотя это хорошая отправная точка.

Для начала, если вы работаете с Entity Framework (или решите переключиться с Linq на SQL позднее), JsonResult прекратит работу, потому что не может сериализовать графы объектов с циклическими ссылками (обычно это большинство моделей данных). Во-вторых, он предоставляет несколько конечных точек для одного и того же ресурса.

Правильный способ сделать это - посмотреть на X-Requested-With HTTP-заголовок, чтобы определить, является ли это запросом XHR. Или Content-Type: text/xml заголовок запроса для XML.

Я бы порекомендовал вам установить плагин Firefox для REST-тестирования , который имитирует XHR-запросы. Плагин Tamper Data и некоторые другие позволяют лучше контролировать тестирование / отладку. WFetch - это простой необработанный инструмент HTTP-запросов, который также необходим для тестирования и отладки.

Я написал фильтр действий JSON / POX для этого. Вам просто нужно украсить ваши классы или методы с помощью атрибута [JsonPox], и они будут автоматически отображаться как JSON или XML в зависимости от клиента.

Answer 2

После прочтения поста Хаака об использовании расширений для указания типа контента, я думаю, вам лучше отключить Accept Header. Мне кажется, больше отдохни, хотя и немного сложнее запустить браузер и проверить свой URL.

Я прочитал небольшую статью в блоге о том, как это сделать и как использовать ModelBinder для абстрагирования HttpContext от вашего контроллера: http://jberke.blogspot.com/2009/03/aspnet-mvc-model-binder.html.

Кроме того, в ответ на дополнительный комментарий Троя я использовал представление для визуализации Xml моей модели. Это позволило мне иметь разные форматы XML для одной и той же модели. Что имеет смысл. Что делать, если вам нужно поддерживать управление версиями или разные форматы для разных клиентов. Мне не нравится идея фреймворка, автоматически отображающего что-либо.

Answer 3

Возможно, вы захотите взглянуть на этот пост в блоге и последующее обсуждение Фила Хаака:

http://haacked.com/archive/2009/01/06/handling-formats-based-on-url-extension.aspx

Его код использует запрошенное расширение файла (.html, .json, .xml) для определения выходных данных, но вы также можете легко использовать Accept-Encoding (или оба).

Примечание: Я оставил комментарий к сообщению Фила и все еще твердо убежден, что необходимо выполнить действия, чтобы подписаться на те методы рендеринга, которые они поддерживают. При рендеринге HTML вы контролируете, какая часть данных отображается для конечного пользователя. Рендеринг XML / JSON, скорее всего, отобразит все, что вы передаете в viewdata, независимо от того, хотите ли вы, чтобы оно было публично видимым или нет.