PATCH mutating single entity property

For REST, the usual answer is that you use the same resource identifier that you would use to GET the representation, and ideally a general purpose patch document to describe the changes you want made to the representation.

(For bonus points, you would advertise support for patch via OPTIONS and the Accept-Patch header).

An example patch request might look like

PATCH /cd16561e-edbc-4151-9f06-b47ef5ddb439
Content-Type: application/json-patch+json
[
{ "op": "replace", "path": "/status", "value": "PENDING" }
]

A key idea in REST is that your service, where you actually store and manipulate information, operates behind a facade that looks like a document store. So we send information (like changes of entity status) to a server using an unsafe HTTP request addressed to a resource that includes a representation of that entity.

The resource identifier? that can be anything that makes sense; but idiomatically it would usually be the same identifier that you would use to GET the resource whose representation is constructed from the entity. In other words

GET /entity/12345
PUT /entity/12345
PATCH /entity/12345

These all go together, as part of your "remote authoring" toolkit.

This is part of the "uniform interface" constraint at work: all resources are expected to understand messages the same way, which in turn allows us to use general purpose components (web browsers, proxies) that know enough about the "transfer of documents over a network" domain to do interesting things.

In terms of trade offs.... doing it this way, in practice, really doesn't win you a whole lot. Remote authoring analogs of "browsers" aren't especially common, and if your clients are going to artisanally craft their HTTP requests anyway (and especially when the bulk of your clients are your own organization - backend-for-frontend and the like), then maybe there are wins to be had via a different approach.

For instance, you might prefer a more RPC like "every interesting edit has its own resource/family of resources", because it makes implementing access control simpler, or because it gives you access logs that facilitate postmortem analysis, or whatever.

Alternatively, if you were using web browsers as your preferred client interface; HTML has battle tested support for POST, so you might give PUT/PATCH a miss and use forms exclusively as the interface for sending information to your server (that would leave you with similar questions about the resource URI to use, but with web forms you tell the client what target to use, so change is less of a hassle than it is in the "guess the URL" cases).

Instead of a bunch of endpoints for mutating a single property, consider just one endpoint for patching any number of properties of an entity.
You might support an optional fingerprint for the status of the other properties, and an optional fingerprint for the prior state of the modified properties to make the modification conditional.

Thus, you get results 200 ok / 204 no content, 412 Precondition Failed, or possibly 404 not found and 401 unauthorized.

With all these "RESTful" questions there is a strong argument for "Just use POST"

If you were being properly RESTful your patch endpoint would allow full editing of the resource. (as per Deduplicators answer)

Your business requirements are to allow the changing of the status only, with presumably a whole bunch of checks and validation.

The solution that fits these requirements is a single RPC style "update status" endpoint, which implements all the logic involved for updating a status, not just editing the resource property to a new value. Callers are always going to use a client library, so the HTTP semantics can be fully hidden from humans and you don't have to worry about RESTfulness.

TLDR; first consider a simpler PUT based solution before implementation PATCH

Say, you need to update a task status. I reckon, PATCH is appropriate. The request must include the task id as well as a new status (IN_PROGRESS, DONE, etc.). Your API should also expose means to assign a user to a task.

PATCH is definitely an option here and it can be a really useful solution in a lot of scenarios. The downside is that it's not the simplest approach to the problem. The simpler, standard REST/HTTP solution to updates is a PUT. The client retrieves the current state of the resource, changes what it needs to change, and then updates with a PUT.

That approach is simple to understand and easy to implement. This isn't without potential downsides, however. PATCH would not have been added to the REST pantheon if PUT met everyone's needs in all scenarios. There are a variety of reasons you might decide to implement PATCH instead of using PUT. But first, I want to note that using PUT naively has a big problem: dirty writes. That is, if two clients are trying to update a resource more-or-less simultaneously, one may overwrite the other's changes. Using PATCH instead is one solution to this but you address this challenge while still using PUT with optimistic locking. For example, using a version number (e.g. eTag) to identify the version of the resource that was retrieved and specifying that you are updating that version in the PUT allows the server to reject the dirty write. This, of course, puts some onus on the client to handle that situation. If there's not much chance of collision and/or the cost of dealing with those collisions is low, this can be a perfectly adequate solution.

I would, in general, prefer this solution to PATCH unless there are reasons that make it problematic or unworkable. As noted above, in a high-contention application, where many clients are updating the same resources, this may not work well. In the worst case, you could have outright starvation where some clients are unable to get their changes through. That's not typical but you can still have problems with optimistic locking that are significant when contention is a concern. Another concern might be if the content of the resource is large, retrieving it and sending it in full just to modify a small part of it might be costly. There are surely other reasons that you might find PUT to be insufficient in addition to these two.