Conventional wisdom says that REST APIs should be implemented as follows:
This mostly works well. Query parameters can be used to supply arguments for
POSTs can use either URL-encoded or multipart form data, standard encodings supported by nearly all HTTP clients.
However, it doesn’t work quite as well for
PUT has no standard encoding, and requires the entire resource to be sent in the payload.
PATCH was introduced as a workaround to this limitation, but it also lacks a standard encoding, and is not supported by all clients (notably Java).
POST method can also be used to modify resources. The semantics of
POST are less strict than
PUT, so it can support partial updates, like
PATCH. Further, the same encoding used for creating resources (URL-encoded or multipart) can also be used for updates.
POST /products– add a new resource to the “products” collection using the data specified in the request body
POST /products/101– update the existing resource with ID 101 in the products collection using the (possibly partial) data specified in the request body
This approach works particularly well when resources are backed by relational database tables. An “add”
POST maps directly to a SQL
INSERT operation, and a “modify”
POST translates to a SQL
UPDATE. The key/value pairs in the body (whether URL-encoded or multipart) can be mapped directly to the table columns.
The approach also supports bulk inserts and updates.
POSTing a URL-encoded payload works well for individual records, but JSON, CSV, or XML could easily be used to add or update multiple records at a time.
So, do you really need
PATCH? Given that
POST is more flexible, better supported, and can handle both create and update operations, I’d say no. Please share your thoughts in the comments!