Is it okay to use a 'HttpPut' or 'HttpPatch' verb and allow the API method not to check for a Patch doc or resource?

Question

I'm not sure what the correct procedure is, when you have a question based off an answer you read but it is a seperate question that arose because of the answer provided.

the answer in question Which HTTP verb should I use to trigger an action in a REST web service?

Walkthrough of my method, where this is relevant

[HtpPut("StartDate/{id}")]
public async Task<IActionResult> StartDate(int id)
{
    //do checks to see if resource exists, and authorisation .
    //start backend task
    //if task successfully starts update 'isStarted' field for the entity with the inputted id
    //return status code 200 if there is no errors 
}

Question when designing an API that adheres to REST as much as possible, is it okay practice in a situation like above to use a 'HttpPut' or 'HttpPatch' verb and allow the API method not to check for a Patch doc or resource? ie: the user sends a request, with whatever resource or patch doc they wish and the server does not care as long as the request id is valid and the user is authorized.

secondary question if this adheres to REST(or even if it deviates from REST), is what I am doing a good solution that is acceptable, or is there a cleaner design I should be implementing for a situation like this?

Answer 1

Here's something important that Fielding said about the HTTP specification

HTTP does not attempt to require the results of a GET to be safe. What it does is require that the semantics of the operation be safe, and therefore it is a fault of the implementation, not the interface or the user of that interface, if anything happens as a result that causes loss of property (money, BTW, is considered property for the sake of this definition).

By extension, the HTTP specification doesn't say anything about how you have to implement the handling of a PUT request, or a PATCH request. What it does say is that, when things go wrong, the implementation is at fault if the behavior doesn't match the semantics.

See also: It Is OK to Use POST.

For example, it isn’t RESTful to use GET to perform unsafe operations because that would violate the definition of the GET method in HTTP, which would in turn mislead intermediaries and spiders. It isn’t RESTful to use POST for information retrieval when that information corresponds to a potential resource, because that usage prevents safe reusability and the network-effect of having a URI. But why shouldn’t you use POST to perform an update? Hypertext can tell the client which method to use when the action being taken is unsafe. PUT is necessary when there is no hypertext telling the client what to do, but lacking hypertext isn’t particularly RESTful.

...

POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”

Answer 2

Q1. Is it RESTFul?

There isn't enough detail in the REST "spec" to say one way or the other.

Q2. Is it a good solution?

The very fact that you are having to ask this question and that your previous question got multiple conflicting responses shows that what you are doing is not a "good solution"

The point of using existing HTTP verbs and specifications to send API messages is simplicity and discoverability. What you are doing is not simple or discoverable.

The alternative, Just Use Post and make an RPC style call isn't RESTful, but at least it's simple and everyone will understand it