For now I do have a specific URL which I call "api/v1/start" in order to start emails queue sending. But I'm afraid that it is not in comply with the REST standard.
REST doesn't care what spelling you use for your resource identifiers.
/api/v1/start is fine.
(Technically, Roy Fielding has had very unkind things to say about the
v1 part. That's a different issue than the one you are currently asking about, though)
How can I add this feature on my RESTfull service. And... Is REST a good option for this demand or should I ignore it?
There are two common patterns.
One is to POST a message to some endpoint, that understands how to interpret the message and do the right thing. This is analogous to what we do when we submit a web form in a browser. The consumer needs to know which links to follow, and to identify the fields it needs to change, and then the message goes wherever.
The other pattern is a more declarative approach, where you PUT a representation of the way you want the resource to be, and the origin server interprets the new representation and figures out how to bring that about.
Example: imagine trying to write a REST api for a kitchen oven. The oven is off, and our goal is to turn it on with a target setting of 450F.
In the first approach, we would
GET the current representation of the oven, and it would have a form on in, with semantic cues explaining the different fields. We would enter 450F into the form, and submit it. That would be converted into a POST request, and sent to the server for processing.
In the second approach, we would
GET the current representation of the oven, with semantic cues telling us the current temperature. Using our favorite editor, we would modify our local copy of the representation with the desired temperature of 450F, and then
PUT the new representation back to the server, which would then figure out how to achieve our desired target state.
What does Roy Fielding Says?
See, for example, this tweet from 2013
a "v1" is a middle finger to your API customers, indicating RPC/HTTP (not REST)