Should I end a controller's action the instant a problem is found in a request?

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开发者_Python百科 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?

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.

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

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.

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.