响应消息:复合消息或可选字段

发布于 2024-12-09 03:37:15 字数 725 浏览 0 评论 0原文

我们正在使用一组 Web 服务,并且正在寻找向 Web 服务的使用者返回错误的最佳选择。这是当前的响应:

响应

  • 有关服务器的一些数据
  • 有关用户的一些数据
  • 执行事务的一些结果数据

因此,我们也需要返回错误。这些是我们的选项:

复合消息

我们将返回两种响应,具体取决于交易是否获得批准或有错误:

第一个:

  • 类型标识符(此消息已序列化。所以我需要知道我正在处理哪种消息,反序列化最后一部分)
  • 关于服务器的一些数据
  • 关于用户的一些数据
  • 执行事务的一些结果数据

第二:

  • 类型标识符(这个消息是序列化的。所以我需要知道哪种消息我正在处理,反序列化最后一部分)
  • 有关服务器的一些数据
  • 有关用户的一些数据
  • 错误

可选字段

交易数据和错误字段将是可选的。如果没有错误,我就会知道它已获得批准。

  • 有关服务器的一些数据
  • 有关用户的一些数据
  • 执行事务的一些结果数据
  • 错误

哪个选项更合适?

We are working with a set of web services and we're looking for the best option to return errors to the web service's consumer. This is the current response:

Response

  • Some data about the server
  • Some data about the user
  • Some resulting data of executing the transaction

So, we need to return errors too. these are our options:

Composite message

we'll return two kinds of responses depending if the transaction was approved or had an error:

First:

  • type identifier (this message is serialized. so I need to know which kind of message I'm dealing with, to deserialize the last part)
  • Some data about the server
  • Some data about the user
  • Some resulting data of executing the transaction

Second:

  • type identifier (this message is serialized. so I need to know which kind of message I'm dealing with, to deserialize the last part)
  • Some data about the server
  • Some data about the user
  • The errors

Optional fields

the transaction data and error fields will be optional. if there's no errors I will know it was approved.

  • Some data about the server
  • Some data about the user
  • Some resulting data of executing the transaction
  • The errors

Which option is more appropriate?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

酷炫老祖宗 2024-12-16 03:37:15

这是有争议的,更多的是个人意见而不是最佳实践。

我个人喜欢使用可选字段,因为错误代码可能是操作的结果。我希望客户端在解析结果之前始终首先检查返回结果的(可选)错误属性。这还允许同时返回非致命错误和部分结果。独一无二,让它如此……独一无二。可选性更加灵活。

This is discutable and more of a personal opinion than a best practice.

My personal favor is to use the Optional fields, because the error code is possible outcome of an operation. I would expect the client to always first check the (optional) error properties of the returned result before parsing the results. This allows to also return non-fatal errors and partial results together. Exclusive makes it so ... exclusive. Optional is more flexible.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文