问题描述
以 RESTful 方式使用 WCF 看起来很棒.我非常喜欢简单性和灵活性这样的大炮，但我也喜欢 Urls 最终的外观.怎么说呢，我是程序员.
Using WCF in a RESTful way seems great. I’m a big fan of the big guns like simplicity and flexibility, but I also love the way the Urls end up looking. What can I say, I’m a programmer.
用于检索和编辑资源的简单 API 与一组几乎同样简单的可能错误响应相匹配，我不禁感到，为了保持纯粹"的 RESTful 方法，我可能会不屑一顾通过面部，或更具体地说，通过我的 Web 服务消费者的鼻子.我可能是错的，但似乎没有太多我可以使用的 Http 错误代码，也没有办法传回自定义错误消息.
The simple API for retrieving and editing resources is matched by an almost equally simple set of possible error responses, and I can’t help feeling that to keep to a "pure" RESTful approach I may be cutting my nose off to spite by face, or more specifically, the nose of my web service consumers. I could be wrong, but there doesn’t seem to be very many Http error codes that I can use, and no ways to pass back a custom error message.
澄清一下，我说的是适当的异常错误，而不是预期的错误.我想向用户实际传达一个问题，以帮助他们确定他们需要做什么来纠正它.
To clarify, I am talking about proper exceptional errors and not expected errors. I want to actually communicate a problem to the user to help them identify what they need to do to correct it.
我正在考虑的可能选项...
Possible options I am considering...
仅使用 Http 错误代码 – 这似乎对我能够表达的内容过于严格，并且不允许我提供自定义消息.如果我错了，请(！)纠正我.
Just use the Http error codes – This seem like it would be too restrictive in what I am able to express, and won’t allow me to supply a custom message. Please(!) correct me if I am wrong.
总是返回 Http Success 但返回自定义错误对象 – 显然是最灵活但肯定不是最 RESTful 的.
Always return Http Success but return custom error objects – Obviously the most flexible but certainly not the most RESTful.
如果有人能分享一些关于这个特定问题的真实世界经验，我将不胜感激.
I would really appreciate it if anyone could share some real world experience of this particular problem.
感谢您建议使用 OutgoingWebResponseContext 对象的 StatusDescription 属性.起初似乎是我可以使用的东西.
Thanks for the suggestion of using the StatusDescription property of the OutgoingWebResponseContext object. It seemed at first to be something that I could use.
我得出的结论是，上面的第二个选项不适合我.我想坚持Http能给我的东西.
I have come to the conclusion that my second option above is not for me. I want to stick to the what Http can give me.
但是，我在让它工作时遇到了问题.无论我为此属性提供什么值，它都不会在响应中返回.
I am having problems getting it to work, however. Regardless of the value I supply for this property, it doesn’t get returned in the response.
我的服务方法是这样的
public MyType GetMyTypes(string criteria)
{
try
{
return GetMyTypes();
}
catch (Exception ex)
{
OutgoingWebResponseContext response = WebOperationContext.Current.OutgoingResponse;
response.StatusCode = HttpStatusCode.Forbidden;
response.StatusDescription = "A Big fat error occurred";
return null;
}
}
这是原始响应消息.没有提到自定义消息...
And here is the raw response message. There is no mention of the custom message...
HTTP/1.1 403 禁止
服务器:ASP.NET 开发服务器/9.0.0.0
日期:格林威治标准时间 2009 年 1 月 7 日星期三 14:01:20
X-AspNet-版本:2.0.50727
缓存控制:私有
内容长度:0
连接:关闭
这并不是说我只需要访问客户端上的正确属性.信息根本没有通过链接发送.
It's not as if I just need to access the correct property on the client. The information is simply not being sent across the link.
这个 StatusDescription 属性实际上有什么作用?
What does this StatusDescription property actually do?
我从来没有发现如何设置 StatusDescription 属性.我最终完全没有包含任何错误消息，并且仅使用 Http 状态代码.我选择为我的服务公开 Soap 和 Restful 端点，因此客户端可以选择他们喜欢使用的端点 - 简单的 Restful 消息或相对丰富的 Soap 消息.
I never did find out how to set the StatusDescription property. I ended up not including any error message at all, and going solely with the Http status codes. I have chosen to expose both Soap and Restful endpoints for my services, and so clients can choose which they prefer to use – the simple Restful messages or the relatively richer Soap messages.
推荐答案
发送正确的响应代码，您可以在响应正文中提供自定义错误消息.
Send the proper response code and you can supply the custom error message in the body of the response.
这篇关于以 RESTful 方式从 WCF 服务返回错误的最佳方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！