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.
I had the same problem, and unfortunately, it looks like the answer is "this is a feature."
Read more here:
Ok, I tried to post a link to the issue description, but it says 'new users can't post links.' So instead, the best I can do is this: do a Google search for "IIS 6: Form Post Data Missing in 404/405 Custom Error Handler" (make sure it's in quotes), and at least at the time of my writing this, the top result should be the page I was referring to.
In summary, what is happening is:
1) Your non-existent URL is POST'd to (e.g., mydomain.com/somepage)
2) IIS receives the request, notes that somepage doesn't exist, and it then fires up a second request to your error handler, and the method for that request is, internally, GET. And none of your POST data is passed along.
That leaves the question as to why you are every having success on IIS 6--that has me baffled.
At any rate, read the above link for more.
Incidentally, I'm running PHP on IIS 6/Windows2003, and I discovered an interesting workaround. While PHP does not receive the POST variables from IIS (as you would expect), PHP still has access to a raw input stream, identified by "php://input", which it can read the original request body from. This will contain the POST variables, in a raw format--I was able to use PHP's parse_str() function to get the POST variables out of that raw string.
So, it might be possible to do something similar in ASP.NET. Have you tried inspecting Request.InputStream? If my memory serves me correctly, that will give you a stream that you can read from. Maybe it will have the raw POST data?
-Josh
Best Answer
Your "web service extension lockdown policy" is preventing the ASP.NET 4.0 ISAPI extension from processing your request. It happened to me, check it out:
Do you have a "0" next to the v4.0 aspnet_isapi.dll like I did? There's your problem. You need to enable it:
For more info on the iisext.vbs tool: http://support.microsoft.com/kb/328419/