You can expose the service in two different endpoints.
the SOAP one can use the binding that support SOAP e.g. basicHttpBinding, the RESTful one can use the webHttpBinding. I assume your REST service will be in JSON, in that case, you need to configure the two endpoints with the following behaviour configuration
<endpointBehaviors>
<behavior name="jsonBehavior">
<enableWebScript/>
</behavior>
</endpointBehaviors>
An example of endpoint configuration in your scenario is
<services>
<service name="TestService">
<endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
<endpoint address="json" binding="webHttpBinding" behaviorConfiguration="jsonBehavior" contract="ITestService"/>
</service>
</services>
so, the service will be available at
Apply [WebGet] to the operation contract to make it RESTful.
e.g.
public interface ITestService
{
[OperationContract]
[WebGet]
string HelloWorld(string text)
}
Note, if the REST service is not in JSON, parameters of the operations can not contain complex type.
Reply to the post for SOAP and RESTful POX(XML)
For plain old XML as return format, this is an example that would work both for SOAP and XML.
[ServiceContract(Namespace = "http://test")]
public interface ITestService
{
[OperationContract]
[WebGet(UriTemplate = "accounts/{id}")]
Account[] GetAccount(string id);
}
POX behavior for REST Plain Old XML
<behavior name="poxBehavior">
<webHttp/>
</behavior>
Endpoints
<services>
<service name="TestService">
<endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
<endpoint address="xml" binding="webHttpBinding" behaviorConfiguration="poxBehavior" contract="ITestService"/>
</service>
</services>
Service will be available at
REST request
try it in browser,
http://www.example.com/xml/accounts/A123
SOAP request
client endpoint configuration for SOAP service after adding the service reference,
<client>
<endpoint address="http://www.example.com/soap" binding="basicHttpBinding"
contract="ITestService" name="BasicHttpBinding_ITestService" />
</client>
in C#
TestServiceClient client = new TestServiceClient();
client.GetAccount("A123");
Another way of doing it is to expose two different service contract and each one with specific configuration. This may generate some duplicates at code level, however at the end of the day, you want to make it working.
A simple RESTful pattern for batches is to make use of a collection resource. For example, to delete several messages at once.
DELETE /mail?&id=0&id=1&id=2
It's a little more complicated to batch update partial resources, or resource attributes. That is, update each markedAsRead attribute. Basically, instead of treating the attribute as part of each resource, you treat it as a bucket into which to put resources. One example was already posted. I adjusted it a little.
POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]
Basically, you are updating the list of mail marked as read.
You can also use this for assigning several items to the same category.
POST /mail?category=junk
POSTDATA: ids=[0,1,2]
It's obviously much more complicated to do iTunes-style batch partial updates (e.g., artist+albumTitle but not trackTitle). The bucket analogy starts to break down.
POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]
In the long run, it's much easier to update a single partial resource, or resource attributes. Just make use of a subresource.
POST /mail/0/markAsRead
POSTDATA: true
Alternatively, you could use parameterized resources. This is less common in REST patterns, but is allowed in the URI and HTTP specs. A semicolon divides horizontally related parameters within a resource.
Update several attributes, several resources:
POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk
Update several resources, just one attribute:
POST /mail/0;1;2/markAsRead
POSTDATA: true
Update several attributes, just one resource:
POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk
The RESTful creativity abounds.
Best Answer
Your understanding of REST is misguided. This is not surprising nor your fault. There is far, far more mis-information about REST floating around on the internet than there is valid information.
REST is far more suited to the coarse-grain document style type of distributed interface than it is for a data oriented CRUD interface. Although there are similarities between CRUD operations and the HTTP GET/PUT/POST/DELETE there are subtle differences that are very significant to the architecture of your application.
I don't think you mean REST over SOAP. It is possible to do REST over SOAP, but to my knowledge nobody does it, and I have never seen an article talking about it.
SOAP is usually used for "Web Services" and REST is usually done over HTTP.