The first option is clearly not REST; you have "actions" in the URI and use POST , which should create a new resource that you are not explicitly trying to do.
Let's only look at the URI format. The second option is improving, but query strings of this nature are larger for reading data. Nothing really prevents you from doing it this way. Option 3 has the best URI format, it only refers to which resource you want to reference in your request.
If we consider the request method. In my book, this is quite simple, I believe that status is only one field of this resource, therefore, if you do only a partial update, you correct the resource, and therefore PATCH is the method that should be used. In case of accident, "status" is the only property, then changing the status completely changes the resource, and therefore PUT will be acceptable; but I doubt that this is true.
Accordingly, the URIs of the third option, combined with the use of PATCH , are probably the best option.
PATCH /resources/{resource_identifier} { "status" :"close" }
Of course, you could also combine this with the concept of expanding certain attributes through your own URI, as if they were the resource itself. Honestly, I don't like this because it seems rather strange and only works on one attribute at a time. However, if this is what you wanted to use, you could have something like:
PUT /resources/{resource_identifier}/status close
Keep in mind that there is no “right” way to do REST, just “not bad”. This is a style, not a set of rules.
I also suggest that you think that the ability to accept many formats is a desirable feature, generally speaking. Thus, the first option is usually easier to work with. You can take JSON, as in the example, or exchange it for XML <status>close</ status> , or a pair of status=closed key pairs, etc.