Suppose I have this simple contract which I’ve taken from MS examples and altered a bit:
[ServiceContract(SessionMode = SessionMode.Allowed)]
public interface IService
{
[WebInvoke(Method = "POST", UriTemplate = "", ResponseFormat = WebMessageFormat.Xml,
RequestFormat = WebMessageFormat.Xml),
Description(
"Adds a customer to customers collection. The response Location header contains a URL to the added item.")]
[OperationContract]
Customer AddCustomer(Customer customer);
[WebInvoke(Method = "DELETE", UriTemplate = "{id}"),
Description(
"Deletes the specified customer from customers collection. Returns NotFound if there is no such customer.")
]
[OperationContract]
void DeleteCustomer(string id);
[WebGet(UriTemplate = "{id}"),
Description(
"Returns the specified customer from customers collection. Returns NotFo`enter code here`und if there is no such customer.")
]
[OperationContract]
Customer GetCustomer(string id);
[WebGet(UriTemplate = ""), Description("Returns all the customers in the customers collection.")]
[OperationContract]
List<Customer> GetCustomers();
[WebInvoke(Method = "PUT", UriTemplate = "{id}"),
Description("Updates the specified customer. Returns NotFound if there is no such customer.")]
[OperationContract]
Customer UpdateCustomer(string id, Customer newCustomer);
}
I need this contract to expose over webhttp REST and over nettcp binding (with sessions).
My case(contract) is much harder, so I need to understand whether to have one implementation for both purposes and differentiate somehow between webhttpbinding call or nettcpbinding call or provide different realizations for each endpoint.
Thanks in advance
I think you do not need to mix different architectural styles – SOAP/WS-* (nettcpbinding) and REST. With correct implementation they have differences. And when you will be mixing such styles in one service, logic for your services methods will contain definitely multiple if-than or switch cases to determine in which mode you are working, also that could be problems when working both with HTTP or WCF contexts.
I suggest you to create to separate endpoints(contract) – one for REST and one for WS-*/SOAP and follow their architectural styles.
To share logic between them, encapsulate your business logic in separate layer (classes) and then you can simply reuse it without mixing REST or WS-* specific logic and your business logic.
When dealing with simple CRUD operations, consider to use WCF Data Serivces, that could generate REST/OData endpoints for you based on database.
UPD from comment:
You can work with stateless REST service but “emulate” your session. As example, it’s common to pass user authentication result token in special ‘Authentication’ HTTP header in each request to recognize and differ users. Such header is passed with each request and actually emulates session with authorized user. So, when session is only one reason for two endpoints, than this problem could be resolved with only one of them.