3

I'm not sure what the expected behavior would be for the following scenarios:

PATCH Request 1: 

"body": {
    "un_updatable_field" : "data" 
}

So here I'd simply throw an exception: Field cannot be updated, whatever.

PATCH Request 2: 

"body": {

    "all_required_fields" : "all",
    "un_updatable_field" : "data" 
}

What should I do here? Throw an exception and don't update the model?

Kyle
  • 667
  • 6
  • 28

2 Answers2

4

Patch operations should be atomic, per the spec:

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. The determination of what constitutes a successful PATCH can vary depending on the patch document and the type of resource(s) being modified. For example, the common 'diff' utility can generate a patch document that applies to multiple files in a directory hierarchy. The atomicity requirement holds for all directly affected files. See "Error Handling", Section 2.2, for details on status codes and possible error conditions.

It looks like your specific case would be

Unprocessable request: Can be specified with a 422 (Unprocessable Entity) response ([RFC4918], Section 11.2) when the server understands the patch document and the syntax of the patch document appears to be valid, but the server is incapable of processing the request. This might include attempts to modify a resource in a way that would cause the resource to become invalid; for instance, a modification to a well-formed XML document that would cause it to no longer be well-formed. There may also be more specific errors like "Conflicting State" that could be signaled with this status code, but the more specific error would generally be more helpful.

a 409 Conflict might also be appropriate, depending on the reason the resource cannot be modified.

Community
  • 1
  • 1
Eric Stein
  • 13,209
  • 3
  • 37
  • 52
0

I'm assuming that un_updateable_field is a field that exist in your system, but you don't want to allow people to update it.

You can choose to ignore it, or you can choose to throw an error. What you should do depends on you. I prefer my systems to be strict and not ignore invalid values, because if an invalid value appears it might indicate you have a bug somewhere and it's better to get a hard error so you can fix this bug.

Evert
  • 93,428
  • 18
  • 118
  • 189