Каков наилучший способ внедрения архитектуры RESTful в .NET сегодня?

Ответ 1

Я действительно реализовал или в настоящее время использую все 3 опубликованных варианта, поэтому я дам свое решение. Теперь, когда вы выяснили, на что вы ищете, немного легче ответить.

OData​​STRONG >

OData отлично подходит для внутренних приложений, когда:

• Вы являетесь одновременно сервером и клиентом.
• Вы используете Entity Framework.
• Вы не используете наследование в своих моделях и не ожидаете запроса подкатегорий.

Odata потрясающе, потому что вы можете использовать IQueryable на стороне клиента. Однако это связано с некоторыми ограничениями. У двух из моей головы есть то, что вы работаете с унаследованными моделями немного неудобно, и вы не можете делать вложенные коллекции.

Также существует проблема с тем, что не знаю, что поддерживает поддерживаемые возможности LINQ.

Я бы порекомендовал OData, вам абсолютно необходим уровень сервиса, и вы только планируете выполнять с ними простые операции CRUD. Основная проблема с каждой проблемой OData приводит к жесткой стене, которую вы просто не можете обойти. Клиентский потребительский код действительно лучшая часть, и если вы не используете С#, чтобы потреблять его, вероятно, этого не стоит.

Также, не используя поддержку авто метаданных EF, вы будете писать столько же кода, чтобы соответствовать схеме, к которой ваши потребители могут или не могут писать. Хотя для OData существует оболочка Rails, все это относительно новое. Я не вижу OData в дикой природе, кроме действительно больших партнеров MS.

Аутентификация и фильтрация OData также являются довольно голой бандой. Вы сами будете писать много разрешающего кода, если вам нужно ограничить данные. Если вы хотите, чтобы SELECT * FROM TABLE был ограничен разрешениями, вы должны быть готовы написать какой-то неудобный код.

MVC 2

MVC очень хорош для создания службы RESTful. У вас есть поддержка глагола, а return JSONResult - это просто. Единственным потенциальным недостатком является то, что вы кодируете большую часть обработки ошибок самостоятельно, и все ваши модели просмотра должны наследоваться от базового класса, который показывает коды состояния и сообщения об ошибках.

Вы также можете немного настроить механизм просмотра в зависимости от того, насколько вы хотите, чтобы ваши сообщения отвечали за причудливость или условность. ОГРОМНОЕ преимущество для MVC - это очень расширяемое, и вы можете делать почти все, что захотите. Я очень люблю комбинировать формы /ajax calls/и службы отдыха в одно и то же действие контроллера. Внесите один раз, получите три аромата одной и той же операции. Было бы сложно сделать MVC коротким, потому что его можно скрутить, чтобы сделать практически все, что вам нужно.

Большим преимуществом для службы MVC является то, что вы можете прокрасться немного интерфейса администратора в приложение, которое развертывается вместе с сервисом. Очень удобно не размещать два сайта.

WCF REST

Итак, я использую только WCF-отдых в очень ограниченной емкости, и кажется... хорошо... Я использовал WCF уже 3 года, и я всегда недовольна тем, насколько сложно скомпрометировать его. Точно так же, как ODATA, вы быстро столкнетесь с закрытыми классами и нерастяжимыми пещерами функциональности, если вы уйдете с проторенного пути. Это находится в прямом контрасте с величиной расширяемости MVC.

Другая проблема - ваше здание поверх WCF и все безумие, которое сопровождает его. Я всегда говорил, что требуется, чтобы PhD эффективно использовал WCF. У Рика Стралла была хорошая статья о болевых точках WCF REST. Не уверен, что все изменилось, но его стоит прочитать.

WCF REST выглядит действительно многообещающим, и я использую его прямо сейчас, я просто не знаю достаточно об этом, чтобы рекомендовать.

Основные моменты

• Если вы не знаете своих потребителей, я бы предположил, что вы не знаете свой API. Не создавайте службу до тех пор, пока у вас нет прецедента, и вы можете ее прописать.

• MVC является наиболее расширяемым, и если вы знакомы с тем, как все работает под обложками, вам, вероятно, будет лучше, чем реализовать сложную задачу MS, такую ​​как OData и WCF.

• Все "большие мальчики", такие как Facebook, Amazon, PayPal, Ebay имеют API, которые не соответствуют любому известному шаблону или схеме, например OData. Ваш сервис REST - это то, что вы делаете. Это относится к № 1. Сосредоточьтесь на том, чтобы облегчить работу с первым потребителем.

Ответ 2

Вы должны проверить OpenRasta. Это ориентированная на ресурсы инфраструктура, специально разработанная для реализации архитектур RESTful в .NET, и поддерживает сильную поддержку таких вещей, как согласование содержимого HTTP и аутентификация дайджеста.

Подход OpenRasta заключается в том, что вместо того, чтобы внедрять ваш API в терминах глаголов (действий), ваш API должен определяться с точки зрения ресурсов (которые, как правило, тесно связаны с вашей моделью сущности API) и кодеков, которые обеспечивают развязанное сериализацию/представление из этих ресурсов как XML, JSON, HTML или любой другой формат содержимого, который должен поддерживать ваш API.

Этот открытый исходный код, полностью написанный в .NET, включает встроенную поддержку IoC и инъекции зависимостей (то, как многие из них связаны друг с другом внутри компании) и распространяется по лицензии MIT.

Версия 2.0 была стабильной в течение некоторого времени и используется в производстве в нескольких местах - в первую очередь Huddle.

На мой взгляд, сильная ориентация OpenRasta на ресурсы означает, что он намного ближе к оригинальному видению Roy Fielding для архитектуры RESTful, чем многие из "многоцелевых" web/HTTP-фреймворков, включая WCF и ASP.NET MVC.

Ответ 3

Прежде чем принимать какие-либо решения, имейте в виду, что поддержка HTTP/REST в WCF значительно меняется. См. http://wcf.codeplex.com/. Будет большой объем обратной совместимости, но новая библиотека будет полностью переписываться с точки зрения HTTP и WCF.

Также имейте в виду, что OData, хотя и полезная для определенного подмножества приложений, не является универсальной структурой REST.

Если вам что-то нужно .net, теперь вы действительно хотите сделать REST право, посмотрите OpenRasta. Если вы хотите только REST, потому что у него хороший маркетинговый шум, то ASP.NET MVC, вероятно, будет достаточно для вас. Если вы просто на экспериментальных этапах, я буду следить за новыми библиотеками WCF.

Ответ 4

Я использовал шаблон приложения службы поддержки WCF, доступный в Visual Studio Extension Manager с большим успехом. Если вы хотите быстро начать то, что я буду делать.

Ответ 5

Если ваш проект построен поверх ORM Framework или вы можете хранить все свои данные в коллекциях памяти, OData - это путь. Если нет (т.е. Вы получаете свои данные через хранимые процедуры или что-то подобное), перейдите для служб WCF HTTP (a.k.a. WCF REST) ​​

OData действительно многообещающая и имеет большую гибкость, построенную поверх интерфейса IQueryable. На самом деле это что-то вроде RESTful LINQ. Однако, если у вас нет ORM под ним, вам придется полностью реализовать IQueryable, что почти похоже на реализацию ORM. На этом этапе вам лучше использовать низкоуровневые службы WCF HTTP, которые дают вам больше контроля, и вы можете сформировать свои ресурсы так, как вы хотите. Библиотеки клиентов не будут такими мощными, но не ожидают, что служба будет внедрять все операторы запросов.