Based on the Roy Fielding theory "Representational State Transfer (REST), attempts to codify the architectural style and design constraints that make the Web what it is. REST emphasizes things like separation of concerns and layers, statelessness, and caching, which are common in many distributed architectures because of the benefits they provide. These benefits include interoperability, independent evolution, interception, improved scalability, efficiency, and overall performance."
Actually only the difference is how clients access our service. Normally, a WCF service will use SOAP, but if you build a REST service, clients will be accessing your service with a different architectural style (calls, serialization like JSON, etc.).
REST uses some common HTTP methods to insert/delete/update/retrieve information which is below:
we can understand by it following way:
Step(1) Cretae Interface
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.ServiceModel.Web;
namespace WCFRESTService
{
[ServiceContract]
public interface IRestService
{
[OperationContract]
[WebInvoke(Method = "GET",
ResponseFormat = WebMessageFormat.Xml,
UriTemplate = "xml/{id}",
BodyStyle = WebMessageBodyStyle.Bare)]
string XMLProcess(string id);
[OperationContract]
[WebInvoke(Method = "GET",
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Bare,
UriTemplate = "json/{id}")]
string JSONProcess(string id);
}
}
Step(2) Implements it
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
namespace WCFRESTService
{
// NOTE: If you change the class name "RestService" here, you must also update the reference to "RestService" in Web.config.
public class RestService :IRestService
{
#region IRestService Members
public string XMLProcess(string id)
{
return "Your XML Processing ID is : " + id;
}
public string JSONProcess(string id)
{
return "Your JSON Processing ID is : " + id;
}
#endregion
}
}
Step(3) now setting configuration file as :
<system.serviceModel>
<services>
<service behaviorConfiguration="WCFRESTService.RestServiceBehavior"
name="WCFRESTService.RestService">
<endpoint address="" binding="webHttpBinding" contract="WCFRESTService.IRestService" behaviorConfiguration="WCFRESTService.webHttp">
</endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WCFRESTService.RestServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="WCFRESTService.webHttp">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>
Step(4) Now we can access it following way:
Actually only the difference is how clients access our service. Normally, a WCF service will use SOAP, but if you build a REST service, clients will be accessing your service with a different architectural style (calls, serialization like JSON, etc.).
REST uses some common HTTP methods to insert/delete/update/retrieve information which is below:
- GET - Requests a specific representation of a resource
- PUT - Creates or updates a resource with the supplied representation
- DELETE - Deletes the specified resource
- POST - Submits data to be processed by the identified resource
- HEADSimilar to GET but only retrieves headers and not the body
- OPTIONSReturns the methods supported by the identified resource
- Less overhead (no SOAP envelope to wrap every call in)
- Less duplication (HTTP already represents operations like
DELETE,PUT,GET, etc. that have to otherwise be represented in a SOAP envelope). - More standardized - HTTP operations are well understood and operate consistently. Some SOAP implementations can get finicky.
- More human readable and testable (harder to test SOAP with just a browser).
- Don't need to use XML (well, you kind of don't have to for SOAP either but it hardly makes sense since you're already doing parsing of the envelope).
- Libraries have made SOAP (kind of) easy. But you are abstracting away a lot of redundancy underneath as I have noted. Yes, in theory, SOAP can go over other transports so as to avoid riding atop a layer doing similar things, but in reality just about all SOAP work you'll ever do is over HTTP.
we can understand by it following way:
Step(1) Cretae Interface
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.ServiceModel.Web;
namespace WCFRESTService
{
[ServiceContract]
public interface IRestService
{
[OperationContract]
[WebInvoke(Method = "GET",
ResponseFormat = WebMessageFormat.Xml,
UriTemplate = "xml/{id}",
BodyStyle = WebMessageBodyStyle.Bare)]
string XMLProcess(string id);
[OperationContract]
[WebInvoke(Method = "GET",
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Bare,
UriTemplate = "json/{id}")]
string JSONProcess(string id);
}
}
Step(2) Implements it
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
namespace WCFRESTService
{
// NOTE: If you change the class name "RestService" here, you must also update the reference to "RestService" in Web.config.
public class RestService :IRestService
{
#region IRestService Members
public string XMLProcess(string id)
{
return "Your XML Processing ID is : " + id;
}
public string JSONProcess(string id)
{
return "Your JSON Processing ID is : " + id;
}
#endregion
}
}
Step(3) now setting configuration file as :
<system.serviceModel>
<services>
<service behaviorConfiguration="WCFRESTService.RestServiceBehavior"
name="WCFRESTService.RestService">
<endpoint address="" binding="webHttpBinding" contract="WCFRESTService.IRestService" behaviorConfiguration="WCFRESTService.webHttp">
</endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WCFRESTService.RestServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="WCFRESTService.webHttp">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>
Step(4) Now we can access it following way:
