0

In an interview, I was asked:

When to use Patch and when to use Put?

I replied:

when need to update all fields then PUT else use Patch. 

And the counter question was:

Shall is use PUT for updating all 100 Fields in Employee table 
and Patch for updating 99 Fields?

To which I replied 'Yes'.

What does architecture says and practically am I correct?

Aurélien Bénel
  • 3,775
  • 24
  • 45
fatherazrael
  • 5,511
  • 16
  • 71
  • 155

1 Answers1

1

What does architecture says and practically am I correct?

I'd say you are wrong in a common and completely understandable way. The literature on this point has a lot more noise then signal.

PATCH and PUT are method tokens used to indicate the semantics of the HTTP request. PUT means "make your representation of this resource look like the body of this request". PATCH means "apply the changes in the body of this request to your representation of this resource".

In other words, the semantics of the messages are those of remote authoring -- these are precisely the methods we would use if we wanted to edit an HTML document through the web interface itself.

So if you are writing an HTTP aware document editor, the choice between PUT and PATCH largely concerns two tradeoffs - the size of the HTTP request body, and using general purpose idempotent message semantics. As a general rule, you would choose PUT unless both of the following are true: the patch document representation of the changes is significantly smaller than the document representation, and that you don't want general purpose HTTP components automatically resend requests when responses are lost.

If you are implementing the server - ideally you'd implement both methods, so that the remote client can choose the request message appropriate for its circumstances.

"Number of fields" doesn't really enter into it, because PUT/PATCH is of the transfer-of-messages-over-a-network domain (see Webber, 2011). The employee table is an implementation detail, hidden behind the HTTP interface.

In other words, what we're really trying to do here is make changing fields in the employee table look exactly like copying a document into a document store.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91