我是否应该在请求中发现问题时立即结束控制器的操作?

发布于 2024-10-23 18:52:17 字数 513 浏览 1 评论 0原文

我想知道这种情况的最佳实践是什么:

我有一个客户端,它使用 POST 程序将客户注册到我的 Web 应用程序中的 /register 服务。该请求可以包括N个供客户注册的程序,例如:

{
    customer_id: 123,
    program_ids: [ 1, 2, 3 ]
}

现在,其中一些程序可能无法供用户注册,即它们被关闭。

我想知道在这种情况下我应该如何处理服务器上控制器的请求验证代码?

我认为我的选择是:

  1. 允许控制器将客户可以注册的任何有效程序提交给数据库,因为它遍历数组中的程序,然后向客户端响应一个错误,指出某些内容有效,但不是全部。

  2. 首先验证请求并确保所有程序都可供客户注册。一旦发现错误,控制器应该停止运行并向客户端响应错误请求。

最后,如果我应该选择选项 2,如何停止处理控制器方法中的所有内容并仅响应错误的请求?

I was wondering what the best practice was for this type of situation:

I have a client that makes a POST to register a customer with a program to the /register service in my web app. This request can include N programs for customer to be registered to, for example:

{
    customer_id: 123,
    program_ids: [ 1, 2, 3 ]
}

Now, some of these programs may not be available for the user to register with them, i.e. they are closed.

I was wondering what I should with my controller's request validation code on the server for this situation?

I figure my options are:

  1. Allow the controller to commit any valid program the customer can register with to the db as it goes through the programs in the array and then respond back to the client with an error that says some stuff worked, but not everything.

  2. First validate the request and make sure that all the programs are available for the customer to register. As soon as a bad one is found, the controller should stop running and respond back to the client with a Bad Request.

Finally, if I should go with option 2, how do I stop processing everything in a controller's method and just respond with a bad request?

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

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

发布评论

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

评论(4

舟遥客 2024-10-30 18:52:17

在我看来,选项 1 给用户带来的麻烦最少。从用户的角度思考:在应用程序上检查多个选项,然后收到错误,因为我的一个选择由于某种原因无效,从而阻止了所有其他有效操作的执行,这是特别烦人的。

就我个人而言,我认为最好允许执行任何有效的操作,如果出现问题,请在单独的数组中跟踪该操作(如 Sam 提到的),然后给用户一个通知功能区或显示“嘿,我为您注册了这些程序,但我无法为您注册所有程序。单击此处获取更多信息”,然后可能会出现一个模式弹出窗口,告诉用户哪些程序失败了以及原因是什么。

In my opinion, option 1 would cause the least amount of user headache. Think of it from the user's perspective: It is particularly annoying to be on an application, check multiple options, and then receive an error because one of my selections was invalid for one reason or another which prevents all of the other valid actions from going through.

Personally, I think it is best to allow whichever actions are valid to go through, and if something fails out, keep track of that in a separate array (as Sam mentioned), and then give the user a notice ribbon or something which says "Hey, I signed you up for these programs, but I couldn't sign you up for all of them. Click here for more info", and then perhaps have a modal popup which will tell the user which ones failed and for what reasons.

南城追梦 2024-10-30 18:52:17
  1. 如果无效数据可能来自无心错误,请选择选项一:执行可以执行的内容,然后显示错误消息。

  2. 如果无效数据来自恶意行为(参数伪造等),请选择选项二。要停止处理控制器方法中的所有内容,只需引发一个错误,您可以选择使用 rescue_from

    来处理该错误。

  1. If the invalid data may come from a honest mistake go with option one: execute what can be executed and then show an error message.

  2. If the invalid data comes from malicious behavior (parameters forgery etc) go with option two. To stop processing everything in a controller's method just raise an error, which you can choose to handle with a rescue_from

伴随着你 2024-10-30 18:52:17

我还没有这样做,但很快就会通过一些移动开发来做到这一点,这就是我计划处理它的方式:

如果您正在处理来自移动应用程序或其他的多个帖子条目,我认为最好的办法是是选项 2,创建两个哈希/数组,一个成功,一个失败。

然后,您可以返回 json 或任何您需要的内容,以返回到具有两个数组的不同服务,一个通过,一个失败。

I haven't done this, but will be doing it soon with some mobile development and this is how I plan to take care of it:

If you are dealing with multiple post entries from a mobile app or whatnot I think the best thing to do is option 2 and create two hashes/arrays one successful one failed.

Then you can return json or whatever you need to return to that different service with two arrays, one passed, and one failed.

┊风居住的梦幻卍 2024-10-30 18:52:17

您提供的两个选项之间的选择应该取决于用户要求和用户体验,而不是技术考虑。在您考虑的情况下,对于该服务的用户来说,部分注册会更好,还是同时完成所有注册更重要?

在技​​术实现方面,对于选项 2,您可能需要研究诸如 自定义验证嵌套属性

The choice between the two options you present should come down to user requirements and user experience rather than technical considerations. Would it be better for users of this service to be partially registered in the situation you are thinking of, or is it more important that all registrations be completed simultaneously?

In terms of technical implementation, for option 2, you probably want to look into such things as custom validations and nested attributes.

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