1

我对 WCF 服务比较陌生，所以如果我遗漏了明显的内容，我提前道歉。我的企业使用 EasyPost 作为我们的运输解决方案，我编写了一个 WCF 服务来处理来自 EasyPost 的运输状态 webhook 调用，如下所述： https ://www.easypost.com/docs/webhooks

简而言之，EasyPost 通过 POST 将更新对象作为 JSON 发送。问题是它向同一个服务方法发送了几种不同类型的（不可配置的）更新，我发现很难编写一个包含所有可能性的 DataContract。例如，如果它发送的参数是一个跟踪号更新，那么update.result.status将是一个字符串值；如果是批量状态更新，update.result.status将是一个对象。这有点乱。

我尝试仅处理我关心的更新类型并在其他更新类型上返回 400 状态代码，但 EasyPost 将其解释为中断并将我的服务作为 webhook 端点丢弃。

从我读到的内容来看，我似乎可以放弃数据协定的舒适性，转而使用System.ServiceModel.Channels.Message参数作为包罗万象的内容，然后手动解析消息。不过，这并不是一个明智/干净的解决方案。

我会很感激任何替代方案。

4

1 回答 1

1

这可能不是我可以处理的最好方法，但它确实有效。

我有一个 HTTP 模块，用于识别传入请求是否针对正确的服务方法，如果是，则将 ContentType 标头从“application/json”转换为“text/plain”。

我的服务方法接受内容主体作为 System.IO.Stream 参数。通过将流转换为 byte[]，然后再转换为字符串，我最终得到了 EasyPost 发送的原始 JSON 字符串。

之后，只需使用 Newtonsoft.Json 尝试将 JSON 字符串反序列化为预期的 Type。

即使反序列化失败，我仍然可以记录数据并向调用者发送成功响应。这对我的目的来说已经足够了。

于 2014-05-30T21:42:58.790 回答