Making WCF Speak REST
By default a WCF endpoint wraps every message in a SOAP envelope, which is fine for enterprise interop but unwelcome for a client that just wants plain HTTP and JSON. To expose a true REST-style endpoint, you configure the endpoint with webHttpBinding instead of basicHttpBinding or wsHttpBinding, and attach the WebHttpBehavior (declared as <webHttp/> inside an endpointBehaviors section) which strips the SOAP envelope entirely and lets operations map directly onto HTTP verbs and URI segments instead of SOAP actions.
Cricket analogy: Stripping the SOAP envelope is like removing the formal toss ceremony and match referee paperwork for a quick backyard game — the same batting and bowling still happens, just without the official wrapping that a Test match requires.
WebGet, WebInvoke and UriTemplate
The [WebGet(UriTemplate = "products/{id}")] attribute maps an HTTP GET request onto an operation, binding the {id} placeholder in the URL directly to a method parameter, while [WebInvoke(Method = "POST", UriTemplate = "products")] does the equivalent for POST, PUT, or DELETE. UriTemplate syntax also supports query-string variables, such as "products?category={cat}", and the shape of the payload is controlled separately via WebMessageBodyStyle (Bare vs Wrapped) on the WebInvoke/WebGet attribute together with RequestFormat and ResponseFormat set to WebMessageFormat.Json or Xml.
Cricket analogy: A UriTemplate placeholder like {id} is like a scorecard slot for 'batsman number' that gets filled in with whichever player is actually at the crease — the template stays fixed, only the specific value plugged in changes each delivery.
Hosting and Behavior Configuration
A REST-style WCF endpoint needs a behaviorConfiguration in its endpoint element that references an endpointBehaviors section containing <webHttp/>, and the service is commonly self-hosted or run under IIS via a .svc file with the ServiceHostFactory set appropriately. WebHttpBehavior also exposes properties such as helpEnabled (turns on an auto-generated help page listing operations) and automaticFormatSelectionEnabled, which lets a single operation return either JSON or XML depending on the client's Accept header rather than forcing one fixed format for every caller.
Cricket analogy: Enabling automaticFormatSelectionEnabled is like a stadium's broadcast truck automatically switching between a 4:3 feed for older regional TV stations and widescreen HD for modern networks, depending on what each receiving station requests, from the exact same camera footage.
Limitations Compared to True REST Frameworks
WCF's REST support lacks the rich, first-class model binding and validation pipeline that dedicated frameworks provide, and there's no built-in OData query composition unless you layer in WCF Data Services separately. Setting an HTTP status code requires manually reaching into WebOperationContext.Current.OutgoingResponse.StatusCode rather than simply returning a typed ActionResult, and by default an unhandled exception doesn't automatically translate into a clean HTTP error response — you need a custom IErrorHandler implementation to convert faults into proper status codes and JSON error bodies instead of letting the default SOAP-flavored fault handling leak through.
Cricket analogy: Manually setting the HTTP status code is like a scorer having to hand-write the match result onto the board themselves because the ground has no automatic scoreboard integration — it works, but it's extra manual effort a modern stadium wouldn't require.
[ServiceContract]
public interface IProductRestService
{
[OperationContract]
[WebGet(UriTemplate = "products/{id}", ResponseFormat = WebMessageFormat.Json)]
Product GetProduct(string id);
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "products",
RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Bare)]
Product CreateProduct(Product newProduct);
}
// web.config endpoint
// <endpoint address="" binding="webHttpBinding" contract="IProductRestService"
// behaviorConfiguration="restBehavior" />
// <endpointBehaviors><behavior name="restBehavior"><webHttp/></behavior></endpointBehaviors>Unhandled exceptions in a webHttpBinding endpoint don't automatically become clean HTTP error responses the way they do in ASP.NET Web API. Implement IErrorHandler and register it via a service behavior so faults are translated into proper status codes (404, 400, 500) with a JSON error body, instead of leaking a default SOAP-style fault or a bare 500 with no useful detail.
- webHttpBinding plus the <webHttp/> endpoint behavior strips the SOAP envelope and enables plain REST/JSON.
- WebGet and WebInvoke map operations to HTTP verbs, with UriTemplate binding URL segments and query strings to parameters.
- WebMessageBodyStyle (Bare vs Wrapped) and RequestFormat/ResponseFormat control the JSON/XML payload shape.
- automaticFormatSelectionEnabled allows one operation to serve either JSON or XML based on the Accept header.
- Status codes must be set manually via WebOperationContext.Current.OutgoingResponse.StatusCode.
- A custom IErrorHandler is needed to turn exceptions into proper HTTP error responses.
- WCF's REST support is an adaptation layer, not a purpose-built REST framework, and lacks built-in OData query composition.
Practice what you learned
1. Which binding must be used to expose a plain (non-SOAP) HTTP/JSON endpoint in WCF?
2. What does [WebGet(UriTemplate = "products/{id}")] do?
3. How must an HTTP status code be set from within a WCF REST operation?
4. What is needed to translate unhandled exceptions into clean HTTP error responses in a WCF REST service?
5. What does automaticFormatSelectionEnabled allow a WCF REST operation to do?
Was this page helpful?
You May Also Like
WCF vs Web API
Compares WCF's protocol-flexible, contract-first model against ASP.NET Web API's HTTP-first, resource-oriented approach, and when to choose each.
WCF Data Services
Introduces WCF Data Services (formerly ADO.NET Data Services) for automatically exposing an Entity Framework model as a queryable OData feed.
WCF Message Exchange Patterns
Explains the three message exchange patterns (MEPs) — One-Way, Request-Reply, and Duplex — that define how messages flow between a WCF client and service.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics