Before you do anything else, read this ebook, it'll take like 20 minutes.: Web API Design by Apigee
It's, imho, one of the best practical REST API design handbooks around and guides you through a lot of the commonalities with advice on which you should do. Actually implementing everything covered can be a bit of a bear, but if you do, you'll have a hell of a service. IT's probably also overkill for an internal service.
Secondly, in terms of documentation, look at the Swagger framework for writing API specifications. Essentially, you describe the API as a YAML or JSON document, then they have tools which will turn that specification into 1) readable and interactive documentation, and 2) Client SDKs. There are also some tools which will generate stub methods for your server-side models from the spec for specific frameworks (SpringMVC, Strongloop Loopback, .Net WebAPI).
Designing a completely new and robust REST API is not trivial, so go slow, and read documentation from good APIs. Don't overengineer - if you're not building the next Amazon, you don't need AWS's level of complexity!
> So although i understand your argument to use POST for this, I need to introduce something that will not cause conflict with this framework convention
Let me put it this way.
Let's say you're passing a non-idempotent action through ~~PATCH~~ PUT (EDIT: typo), say "increase game character magic skill +1".
For some reason your server, or some router along the way or god knows where, traffic slows down and the command is either lost, or the response never comes back.
So an intermediary sees "PUT" and decides "I'm not getting a response, so this means I can re-send, as PUT is idempotent". The intermediary is simply following HTTP, according to spec.
Turns out the message was not lost, just slowed down, so two copies of "increase game character magic skill +1" arrive at the server. Suddenly the user gets +2 increment in magic skill and not +1.
> One question, the framework is trying to follow REST. Correct me if I'm wrong but wouldn't POST on update actions contradict the RESTfulnes ?
No, but sending non-idempotent actions over PUT would contradict HTTP itself, and you risk actions being sent multiple times to your server in certain conditions.
Actual REST, as well as actual HTTP, are not a matter of conventions, but a matter of specifications. And when you don't follow the specifications, it has implications for whether your app will behave correctly.
Also PUT implies you're replacing the resource at the URL with what you're sending, not merely sending partial updates. If you're sending partial updates, then products like Varnish HTTP Cache will misbehave as well, thinking your "update" is the actual resource to return next time.
Creating a REST(ful) service is possible in any web application framework as REST is simply (or not so simply) a set of rules on top of the HTTP spec as to how verbs, urls, body etc is implemented. That said, .NET does have MVC and Web API project type that lends well to RESTful API design.
Reading the title I thought this might have been about the Insomnia REST client: https://insomnia.rest/
But alas. This subreddit is for programmers talking about APIs. I hope you find some solutions for your problem. (I found that melatonine can help, pretty safe an over-the-counter everywhere; but it's not a permanent solution)