If you haven’t read my previous post on this topic, please go read http://www.silver-it.com/node/160 it since I’m only going to focus on the write operations here. As you know, in REST, whenever you want to create a resource, you should use the HTTP POST verb.In my previous post, I explained how to handle ComplexTypes and Collections with HTTP GET using your own _api endpoints in SharePoint 2013. These operations were all READ operations based on HTTP GET.
To declare a method that can only be called by HTTP POST, you need to implement the following methodinformation:

What is important here is the OperationType attribute that must be set to OperationType.Default.. The other value is OperationType.Read which implicitely allows the HTTP GET. With OperationType.Default, SharePoint knows that he shoudln’t allow that method to be called via HTTP GET but that’s not enough! To enforce it, you need to explicitely tell SharePoint to control the method when invoking it:

So, the important bits here are the call to the base method CheckBlockedMethod. If you omit this guy, SharePoint will allow HTTP GET over that method although you specified OperationType.Default in the method information. In this case I’m returning null but of course, if you have a return value, you should return it as usual. The proxy looks like what we’ve seen in my previous post:

The first request consists in getting the DIGEST that’s required to consume _api endpoints in HTTP POST. When the first request completes, I make a call to my own function. I’m passing the DIGEST and a JSON object to it. Note that alternatively, you can also call your function as in a GET request like this “/_api/silverit/TestMethod(p1=’value’)” but usually one prefer to pass a JSON object via the data property