Применение [WebInvoke (ResponseFormat = WebMessageFormat.Json)] в файле конфигурации

Question

Я пишу то, что я называю веб-службой веб-сервиса POJ (Plain Old JSON) - тот, который принимает и испускает стандартный JSON без какого-либо что ASP.NET Ajax любит добавлять к нему.

Кажется, что есть три шага, чтобы выполнить эту задачу:

1. Изменить "enableWebScript" в "webHttp" в теге конечной точки
2. Украсьте метод с [WebInvoke (ResponseFormat = WebMessageFormat.Json)]
3. Добавить заклинание [AspNetCompatibilityRequirements (RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] к договору оказания услуг

Это все работает нормально для меня - я могу пройти, и мне возвращается хороший простой JSON.

Если я удалю атрибут WebInvoke, вместо этого вернусь к XML, поэтому он, безусловно, делает то, что он должен делать. Но мне кажется странным, что опция указания вывода JSON появляется здесь, а не в файле конфигурации. Скажем, я хотел бы разоблачить мой метод как конечную точку XML - как бы я это сделал? В настоящее время единственный способ, которым я могу видеть, - это иметь второй метод, который делает то же самое, но не содержит WebMethodFormat.Json. Затем промыть и повторить для каждого метода в моем сервисе? Тьфу.

Задание того, что вывод должен быть сериализован для JSON в атрибуте, кажется, полностью противоречит философии WCF, где реализована услуга, является агностическим видом транспорта и кодирования, оставляя неприятные сведения о том, как данные будут переместился в файл конфигурации.

Есть ли лучший способ сделать то, что я хочу? Или мы застряли с этим неудобным атрибутом? Или я недостаточно понимаю WCF?

Answer 1

Я еще не полностью проверил это, НО, я взглянул на WebMessageFormat в отражателе и где он использовался в коде.

Существует атрибут элемента webHttp, называемый defaultOutgoingResponseFormat, который может быть установлен в «Json» или «Xml».

<behaviors> 
     <endpointBehaviors> 
     <behavior name="ServicesJSONEndpointBehavior"> 
      <webHttp defaultOutgoingResponseFormat="Json"/> 
     </behavior> 
</behaviors> 

Я столкнулся с той же проблемой и, как правило, крутыми обходами после поиска в Интернете без большой информации.

Я сделаю снимок с несколькими настроенными конечными точками и отчитаюсь.

UPDATE 6/5/2011

FYI - Я угробил ванильный WCF со всеми его волос-вытягивать сценариев, как это должно быть, что просто в пользу ServiceStack (http://servicestack.net/). Если вы хотите собрать стандартный стиль REST/документально ориентированный сервис по HTTP, который готовый поддерживает JSON/XML/CSV (и в будущих буферах протокола), и это позволяет вам собрать чистый MVC -типы с легкостью, дать ServiceStack жесткий взгляд. Есть ряд вещей, которые ServiceStack будет обрабатывать довольно легко и чисто, которые всегда оказываются крупными PITA из-за некоторой неуверенной проблемы с конфигурацией или аналогичной в стандартном WCF. ServiceStack использует собственный JSON-сериализатор, который в качестве дополнительного бонуса превосходит DataContractJsonSerializer и JSON.NET, как упоминает Demis ниже.