What are the benefits and drawbacks of using PATCH for updating resources?

One of the biggest benefits of using REST over HTTP is engineers can take advantage of all of the tooling developed for the protocol for serving websites and documents: - Content negotiation - Caching - Path-based load balancing - Authentication - Websockets Additionally, firewalls are designed around allowing HTTP through, so there's a lot less in the way of requiring clients of your API to open up specific ports, and Deep Packet Inspection is incredibly unlikely to provide a barrier.

Choosing between PATCH and PUT depends on what we want to achieve with our update operation. If we want to replace the whole resource, we should use PUT. If we want to modify only some aspects of the resource, we should use PATCH. This way, we can communicate our intention clearly and avoid unintended consequences. Using PATCH and PUT correctly is important because it helps us follow the principles of RESTful design, which aim to make our APIs more consistent, predictable and easy to use. It also helps us avoid errors and conflicts that may arise from using the wrong method for the wrong purpose. By respecting the semantics of PATCH and PUT, we can improve the quality and reliability of our APIs.

PUT: Update the whole resource PATCH: Update a specific field inside a resource When we send a "PUT" request to a resource endpoint, we typically send the entire updated representation of the resource in the request body. When we send a "PATCH" request, we provide a partial representation of the resource with only the fields that need to be updated

PATCH is a more flexible and granular method for updating resources, but it requires careful implementation to avoid security risks and compatibility issues. PUT is a simpler and more standardized method, but it can be less efficient and less flexible in some scenarios. The choice between PATCH and PUT depends on the specific requirements and constraints of your application.

• Granularity: PATCH allows you to update only the fields that have changed in the resource, which can be more efficient than updating the entire resource with PUT. • Flexibility: PATCH allows you to update a resource using any format you want, including JSON, XML, or plain text. • Partial updates: PATCH can be used to update a subset of a resource, which can be useful when you want to avoid overwriting other changes made to the resource.

Not unless you are updating specific fields where then PATCH will come in handy, PUT is equally a better alternative where you receive the posted request and sieve through and make partial or full object update

Switch off all verbs except GET and POST. Handle the other verb functions another way. Far too exposed allowing verbs like this unless you want to manage every possible hacking technique out there.

Not very helpful, I thought this was going to propose a way to PATCH entities uniformly. Does anyone really not know what was in the article? They only line worth mentioning is "Third, it can create some inconsistency and confusion in the web API, since it may not be supported by all servers or clients, or may not follow the same patch format or semantics" "introduce some security and validation issues, since it may allow clients to modify fields that should not be changed" is silly since PUT has the same problem and the body needs to be validated on the same way. Was this straight out of ChatGPT?