Should PATCH without any recognized fields return error?

#1

If a PATCH request contains no recognized fields (either because there are no fields at all, or because no fields are recognized), and the server expects fields to patch, should the server return an error?

I’m generally in favor of indicating to the client that something is wrong with the request, but returning an error here might have implications for backwards compatibility, though I’m not sure if it’s relevant in practice. Specifically, removing a resource field will then cause clients that only attempt to patch this field to suddenly start getting errors. But in this case, the client is likely broken anyway since it depends on a field that has been removed. (Also, clients should have ample time to update during a sunset period, so I’m not too concerned about this.)

Any thoughts on whether to return an error for “empty” PATCH requests?

1 Like

#2

I tend to prefer returning an error for that case.

  • No matter what, you are breaking the API (even if the backend doesn’t return an error, because it is not updating fields anymore).
  • Clients probably want to know if something is suddenly wrong.
  • Once you get liberal in what you accept, clients will expect that and complain if you ever decide to toughen up the rules. Show 'em who’s the boss that won’t accept crap.
0 Likes