设计一个简单的Web服务与返回代码的最佳实践

我正在设计一个WCF服务，将返回一个响应代码（如0为成功，或另一个数字的错误）。此外，Web服务的所有方法都将执行几个常见的验证（例如验证apiKey）。设计一个简单的Web服务与返回代码的最佳实践

我想知道是否有最佳实践方法或组织和检索这些响应代码和消息。

感谢您的任何建议。

2010-09-10 dotariel

理想情况下，不要使用响应代码。成功返回可用的东西（或无效）并在失败时抛出异常。

人们处理异常。我们经常忘记查看返回的代码，特别是当99％的时间成功时，我们不关心任何响应。所以我们不捕捉。然后我们不费心检查失败。然后，我们花了2天的时间跟踪一个我们无法找到的错误，因为没有抛出异常，我们不知道600,000行应用程序在哪里使用您的web服务失败...我们甚至不知道这是一个打电话给您失败的web服务。只是由于某些未知原因，某些数据是错误的。

有一个话题在SO一下：Which and Why do you prefer Exceptions or Return Codes

来源

2010-09-10 16:15:01 CaffGeek

乍得，这很有道理。但是，可以从Web服务抛出异常，而不知道服务是从哪个平台消耗的？我最初的想法是建立一个封装代码和消息的DataContract。这将如何被替换为一个异常？ – dotariel 2010-09-10 21:31:35

@ XSaint32，不能说我做了很多，但我不认为这是一个问题。我很确定我有一个调用Java服务的.NET应用程序，它捕获了没有问题的异常。结果最终将被序列化为xml/soap。据我所知，当你添加一个web服务引用时生成的类会处理这个事件。 – CaffGeek 2010-09-10 21:55:19

这种方法将与xml/soap包装器一起工作，但我可能需要使用REST提供这些服务。一个RESTful服务能够抛出HTTP豁免以外的任何东西吗？我需要假定使用Web服务的客户端可能是一个简单的PHP cURL站点。 – dotariel 2010-09-11 00:45:44

不要直接使用返回代码。返回码通常意味着成功，预期失败和意外失败。 Web服务将此机制替换为期望的故障和意外故障。请检查FaultContract和FaultException<T>以获取预期故障的实施细节。意外的错误是其他任何异常。这是最佳做法。

来源

2010-09-10 19:24:37

设计一个简单的Web服务与返回代码的最佳实践

回答

相关问题