Краткий и легкий API: REST + JSON в .NET

Question

Резюме: Мне нужно знать, существует ли в мире .NET легкая реализация REST + JSON, которая не использует WCF.Если нет, я ищу людей, которым было бы интересно создать совместное предприятие для проекта с открытым исходным кодом.

Я не знаю о вас, но я был большим поклонником WCF, когда он вышел, и япохвалил его дизайн за его модульность и расширяемость.Однако, поскольку я использовал это все чаще и чаще, фундаментальные проблемы стали проявляться настолько, что я теперь чувствую, что их нужно пересмотреть и переработать.Это кажется большим заявлением, но я считаю, что это основные проблемы:

1. Прежде всего, WCF внутренне использует SOAP для сообщения, что означает, что если транспортное сообщение не SOAP, мы несем расходы на преобразование.и обратно из SOAP для каждого звонка.Это дорого и требует много времени.
2. Преобразование исходящего сообщения требует «подключения» инспектора сообщений и «кражи» сообщения.Как следует из названия, это инспектор (должен использоваться для проверки и регистрации), поэтому использование его для изменения сообщения, откровенно говоря, является хаком.
3. Это был дизайн в соответствии с WSDL, и мир так сильно изменился с тех пор2001. Реализация REST также требует кражи сообщения.WCF был разработан в соответствии с WSDL, а не REST.
4. Стек каналов неоправданно тяжел.
5. Основной стек не зависит от протокола.Это не преимущество, это фундаментальный недостаток.Как вы знаете, доступ к большому количеству информации уровня протокола был добавлен позже, поскольку было невозможно реализовать некоторые важные пользовательские сценарии.Например, IP-адрес клиента в TCP был недоступен и был добавлен позже (теперь он доступен с помощью perationContext.Current.IncomingMessageProperties [RemoteEndpointMessageProperty.Name])
6. Взаимодействие с другими платформами может быть проблемой.

   Теперь кажется, что многие проекты движутся к простоте JSON и REST.Мне просто нравится их простота, и я вижу, как моя стиральная машина потребляет JSON через 5-10 лет и предоставляет услугу REST!Я считаю, что их реализация в .NET была хакерской, и нам серьезно нужна очень легкая и простая структура (потому что они простые и легкие) для размещения служб REST + JSON внутри и вне IIS.Я надеюсь, что такая основа существует, но если нет, я действительно стремлюсь к тому, чтобы что-то происходило с рядом единомышленников.

   Так что вы думаете?Существует ли такая основа?Если нет, то кому-нибудь интересно?

Answer 1

Взгляните на OpenRasta .Похоже, это решает многие ваши проблемы.

Answer 2

MVC, который выплевывает JSON вместо HTML, кажется возможным.Вы можете свободно использовать JsonDataContractSerializer или JSON.Net для сериализации ваших контрактов данных.

Answer 3

Существует MicroRest , проект с открытым исходным кодом, который я начал некоторое время. Вот реклама, которую я написал:

MicroRest - это крошечный каркас REST - 5 классов, около 500 строк кода. Весь вывод в формате JSON. Это позволяет вам добавлять возможности REST к вашим приложениям ASP.NET без необходимости проходить через огромный и безобразный беспорядок отдыха WCF (который не предоставляет «чистых» URL-адресов в 3.5). Это также позволяет вам использовать POCO (и сложные объекты в некоторых случаях) внутри ваших методов REST, где WCF ограничивает вас использованием целых чисел и строк

Вклады очень приветствуются - сейчас они зависят от System.Web.Routing, поэтому в качестве встроенного веб-сервера необходим Cassini / IISExpress. Я пытаюсь написать собственный анализатор маршрутов, чтобы он мог переместиться на Kayak в качестве некоторой точки.

Answer 4

Если вы действительно не хотите использовать IIS, вы можете реализовать свой собственный процесс прослушивания HTTP. Это позволит вам написать собственное автономное приложение для ответа на HTTP-запросы (которые могут быть запущены как служба, если вы того пожелаете) без каких-либо накладных расходов на IIS, WCF или любую другую инфраструктуру контейнерных процессов. Ваш процесс будет работать поверх функциональности HTTP.sys, предоставляемой Windows, и предоставляться платформой .Net через класс HttpListener.

Взгляните на http://msdn.microsoft.com/en-us/library/system.net.httplistener.aspx

Обратите внимание, что вам нужно будет написать собственную инфраструктуру для сопоставления входящих запросов и отправки их соответствующим обработчикам (эквивалент UrlRoutingModule / RouteTable.Routes / MvcRouteHandler в ASP.Net MVC), и вам потребуется передавать HttpListenerContext повсюду в Чтобы проверить входящий запрос и завершить его. Но это дает вам максимальную гибкость в том, что вы можете сделать.

И это, безусловно, работает - я протестировал базовую реализацию HttpListener на стандартной машине настольного класса со скоростью более 3000 запросов в секунду, поэтому сама структура не будет вас сдерживать.