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 WSDL is an XML document that describes a web service. It actually stands for Web Services Description Language.
SOAP is an XML-based protocol that lets you exchange info over a particular protocol (can be HTTP or SMTP, for example) between applications. It stands for Simple Object Access Protocol and uses XML for its messaging format to relay the information.
REST is an architectural style of networked systems and stands for Representational State Transfer. It's not a standard itself, but does use standards such as HTTP, URL, XML, etc.
Best Answer
You mentioned this is the SOAP service of a printer. Is the printer's API documented on the manufacturer's site? Does the documentation include the WSDL? Can you get the WSDL from the manufacturer?
If you can get the WSDL from the manufacturer then you're done!
If not, then you have to build the WSDL by yourself because I doubt you can find a tool that generates WSDLs given SOAP samples (when working with SOAP web services you mainly get two kinds of tools: those that generate code from WSDL + those that generate WSDL from code).
It's not hard to create the WSDL if you are familiar with SOAP, WSDL and XSD. You just need a text editor or maybe even a WSDL editor to speed things up.
If you don't have full confidence in your WSDL knowledge, there are still some tools that can get you most of the way to the complete WSDL. Here is a way you could do it:
1 - First you need to create the XML schema for the SOAP payloads. For this you can find tools, even some online. After you have the schema, tweak it to your needs by adding, changing or removing elements.
2 - Now you can use the XSD to generate a WSDL. There is an online tool that does that. It just needs the request/response element types to end with Request/Response. Make sure you read the instructions.
You take your XSD file, change the names of the operations to add the Request/Response suffix and feed it to the WSDL Generator - Web Tool. You will get your WSDL.
Now tweak this WSDL as you like (remove the Request/Response suffixes if you don't need them) then ...
3 - ... make sure you end up with a valid WSDL.
4 - Now you can take your WSDL and use a tool like SoapUI to generate sample requests and responses from it just to verify that you get the proper results back.
Do the SoapUI messages match the messages you started with? If yes, you are done and can feed the WSDL to
suds
to create the Linux client. If not, tweak the WSDL until you get the result you are after.