Разработка нового веб-сервиса RESTful в .NET - с чего мне начать? ASP.NET-MVC, WCF?

Question

Цель состоит в том, чтобы создать сервис, который я затем буду использовать через jQuery и основанный на стандартах веб-интерфейс, «толстые клиенты» мобильных устройств и, весьма вероятно, настольное приложение WPF.

Кажется, что WCF был бы хорошим вариантом, но я никогда не создавал RESTful-сервис с WCF, поэтому я не уверен, с чего вообще начать этот подход.

Другой вариант, о котором я думаю, - это использование ASP.NET MVC, добавление некоторых пользовательских маршрутов, добавление нескольких действий контроллера и использование разных представлений для выталкивания JSON, xml и других типов возврата.

Этот проект в основном является обучающим упражнением для меня, и я хотел бы потратить некоторое дополнительное время и сделать это "правильно", чтобы лучше понять, как части сочетаются друг с другом.

Итак, мой вопрос в том, какой подход я должен использовать для создания этого сервиса RESTful, и каковы некоторые преимущества такого подхода?

Answer 1

Обычно я бы сказал, WCF для любого вида размещенной службы, но в конкретном случае для служб RESTful, использующих JSON в качестве механизма сериализации, я предпочитаю ASP.NET MVC (который я буду называть ASP.NET для остальной части этого ответа).

Одна из первых причин - механизм маршрутизации. В WCF вы должны определить это в контракте, что все хорошо, но если вам нужно быстро внести изменения в свою маршрутизацию, с моей точки зрения, сделать это гораздо проще, используя механизм маршрутизации в ASP. NET.

Кроме того, к вышесказанному, если у вас есть несколько сервисов, предоставляемых через несколько интерфейсов в WCF, трудно получить полное изображение вашей структуры URL (что важно), тогда как в ASP.NET вы (как правило) маршрутных назначений в одном месте.

Второе, что есть в ASP.NET, это то, что у вас будет доступ ко всем внутренним объектам, которыми ASP.NET известен (Запрос, Ответ, Сервер и т. Д.), Что необходимо при предоставлении HTTP Конкретная конечная точка (это то, что вы создаете). Конечно, вы можете использовать многие из тех же самых вещей в WCF, но вы должны специально сообщить WCF, что вы делаете это, а затем разработать свои услуги с учетом этого.

Наконец, благодаря личному опыту, я обнаружил, что DataContractJsonSerializer не слишком хорошо обрабатывает значения DateTimeOffset, и это тип, который вы должны использовать над DateTime при работе с услугой (через любую конечную точку), которую могут вызывать люди в нескольких часовых поясах. В ASP.NET есть другой сериализатор, который вы можете использовать, или, если хотите, вы можете создать свой собственный ActionResult, который использует собственный сериализатор для вас. Я лично предпочитаю сериализатор JSON.Net .

Одна из приятных вещей в сериализаторе JSON.Net и ASP.NET, которая мне нравится, заключается в том, что вы можете использовать анонимные типы с ним, если вы умны. Если вы создаете статический универсальный метод для неуниверсального типа, который затем делегирует внутреннему универсальному типу, вы можете использовать вывод типов, чтобы легко использовать анонимные типы для ваших сериализованных возвращаемых значений (конечно, при условии, что они одноразовые, если вы иметь структуру, которая возвращается последовательно, вы должны определить ее и использовать).

Следует также отметить, что вам не нужно полностью сбрасывать со счетов WCF при разработке сервиса RESTful. Если вы выталкиваете ATOM или RSS-канал из своего сервиса, то классы в System.ServiceModel.Syndication пространстве имен массив помогают в создании и сериализации этих каналов. Создать простой подкласс класса ActionResult для получения экземпляра SyndicationFeed и затем сериализовать его в выходной поток при выполнении ActionResult довольно просто.

Answer 2

Вот мысль, которая может помочь вам принять решение между ASP.NET MVC и WCF. В сценариях, которые вы описываете, ожидаете ли вы использовать протокол, отличный от HTTP?

WCF не зависит от транспортного протокола и поэтому сильно отличается от ASP.NET. Он имеет каналы и привязки, сообщения, сервисные контракты, контракты на данные и поведение. Он дает очень мало руководящих указаний, когда речь идет о создании распределенных приложений. То, что он дает вам, это чистый лист, на котором можно строить.

ASP.Net MVC, естественно, основывается на Http. Он касается HTTP-глаголов, типов мультимедиа, URL-адресов, заголовков ответов и заголовков запросов.

Вопрос в том, какая модель ближе к тому, что вы пытаетесь построить?

Теперь вы упомянули ReST. Если вы действительно хотите создавать свои распределенные приложения, следуя ограничениям ReST, тогда вам лучше начать с OpenRasta. Это приведет вас по этому пути.

Вы можете сделать Отдых в ASP.Net MVC, и вы можете сделать это в WCF, но с этими решениями вы не попадете в пропасть успеха ;-)

Answer 3

Лично я не в восторге от внедрения REST-сервисов в WCF. Я считаю, что asv.net mvc framework более естественная модель программирования для этого.

Разработчик http://atomsite.net/ первоначально реализовал спецификацию atompub в WCF, а затем переписал весь сервис, используя asp.net mvc. Его опыт повторил мой комментарий выше, что для чистого сервиса REST asp.net mvc - это путь.

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