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?

  • 4
    Honestly both answers can work. It really depends on whether you believe everything from the patch has to correct and complete. If the idea is that you take the good parts and apply it, with error information about what was not applied is not entirely outside of the concept of PATCH. How "correct" does a patch have to be before you feel you can't use it? Commented Jun 22, 2022 at 11:14

3 Answers 3


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.

  • Thank you @Flater, that makes sense, am going with the same approach, adding it as detail in other answer Commented Jun 22, 2022 at 14:05

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).

  • 2
    While you are correct that this is what the specification mentions, it's not an absolute, as the specification is solely focused on absolute states being passed into the request body. This is not always a given, e.g. if you intentionally provide a fallback value which may not need to be used when the primary value works. The specification is clear about its intentions but it shouldn't be interpreted to be a blanket scripture for every possible use case. It depends on whether OP considers applying some of the passed URLs as a completed operations; which is a business decision.
    – Flater
    Commented Jun 22, 2022 at 14:16

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"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.