What HTTP response to return for a patch request with partially correct and partially wrong

Question

I have a campaign, which has URL as a child. If I make a patch request to add a list of 3 URLs out of which first one is invalid URL, second URL already exists in the campaign and we do not want to duplicate the URL and third one is a valid URL which can be added to campaign.

What should server do?

1. should it return 400 asking to send only valid URLs by stating which one is invalid URL
2. should it return 200, by using the valid URL and returning information about invalid and duplicate URLs?

any other thing?

Answer 1

What the server should do depends on what the intended behavior is according to the business requirements. That is not something that a stranger on the internet can conclusively answer for your specific scenario.

By default, I would err on the side of breaking the request with a clear error message; simply because it could be cumbersome for the user to have to now fix their mistake using a new patch request; as opposed to simply fixing and firing the original request again.
But this is a default assumption on my part as a developer, made without any consideration for any particular business requirements or scenario.

Contextually, for a given business requirement or scenario, it could be perfectly okay that you only process the workable data and be done with it. However, it could also be reasonable to expect the end user to assume that a completed request means that the entire request has been serviced.

If you go with the approach of using what you can and ignoring what you can't use; you also have to decide how to communicate these non-breaking failures. These may come in the form of warnings returned to the user (with a success response), privately logging it, ... Again, you have to look at what your business requirements are and what makes sense to your specific scenario.

Answer 2

The registered reference for the PATCH method is RFC 5789. The description of the method includes this constraint:

The server MUST apply the entire set of changes atomically and never provide (e.g., in response to a GET during this operation) a partially modified representation. If the entire patch document cannot be successfully applied, then the server MUST NOT apply any of the changes.

That suggests that, if you are unwilling to apply the entire patch to the resource, that you should be returning some flavor of client error. The specification of error handling suggests that 422 Unprocessable Content would be most appropriate in this case (in practice, it probably doesn't matter very much).

Answer 3

This is details about the solution which I used in my case, because that is what product owner wants, also corroborated by @flater's answer.

this is how my response would look like if there is at least one valid URL that was correctly added, otherwise I send 400 response complaining that there is no URL which could be added

status: 200,
data : {
duplicate_client_urls: []
duplicate_control_urls: []
error_client_urls: []
error_control_urls: [""]
good_client_urls: ["https://www.abc.com/warranty/home-warranties-worth"]
good_control_urls: []
message: "Fetch job queued for new URLs"
}