www.developer.com/net/article.php/3695436
By Aaron Lerch August 21, 2007 Windows Communication Foundation (WCF) is Microsoft's services-oriented framework for building connected systems using the Microsoft .NET Framework. Although WCF is flexible enough to build arbitrary services-based solutions, its primary story is Web Services. To get the most out of this article, you should have at least a basic understanding of core WCF concepts including messaging, serialization, contracts, and bindings/endpoint configuration. This article was written based on .NET 3.5, the Beta 2 release. Prior to (and including) version 3.5 of the .NET Framework, web services—whether ASMX or WCF—have been implemented using SOAP and the WS-* stack. The WS-* stack is a suite of extensions to the SOAP specification that define advanced systems-level functionality such as transactions, reliable messaging, and more. A web service was typically accessed by performing an HTTP POST to the service endpoint (for example, "http://www.example.com/ExampleService.svc") and sending a SOAP message as the submitted data. Because HTTP is a request-reply protocol, the response to the HTTP request contained a SOAP message describing the relevant response from the server. This approach to web services is by far the most prevalent in use today, and has many compelling features that make it a viable solution to many business problems. However, this approach hijacks features of the HTTP protocol, making it a "carrier" for a completely separate protocol (SOAP). For several years, a discussion has been growing over the idea that the HTTP protocol itself is rich enough to offer the capabilities that many web services require, while simultaneously providing the benefits such as scalability that the World Wide Web has enjoyed for years—benefits that a SOAP-based web service implementation does not enjoy "for free." In .NET 3.5, WCF offers support for both worlds of programming: creating services that can be exposed via a SOAP endpoint, or a "RESTful" endpoint, depending on configuration. An alternate phrase for "REST" is "web programming." REST stands for Representational State Transfer, a term coined by one of the original authors of the HTTP protocol, Roy Fielding, in his 2000 doctoral dissertation. Representational State TransferRepresentational State Transfer is a phrase that describes the generic principles that make up much of what we know to be the HTTP protocol. As it applies to web services, the primary concepts of interest are resources, and the actions that can be taken on a given resource. Resources are identified by Uniform Resource Identifiers (URIs), something that nearly everybody is familiar with. SOAP-based web services typically use a single URI to represent the service endpoint plus an operation. A RESTful web service uses a unique URI to reference every resource, and HTTP verbs to define actions on those resources. As an example, I will reference a simple blog engine—the source code is available for download. At the very basic level, a blog consists of posts and comments made on those posts. Retrieving a single post (a resource) using SOAP-based web services would use URI syntax much like this: "http://blogexample.com/Blog.asmx?op=GetPost" The URI simply serves to identify the service endpoint and the operation to invoke, not the actual resource (the specific blog post). The identifier of an individual post to retrieve would be specified inside the SOAP message contained in the body of the HTTP request. A RESTful web service would use a combination of a truly unique URI and an HTTP verb to retrieve a blog post; for example, performing an HTTP GET request to "http://blogexample.com/blog/post/123456" to retrieve blog post number 123456. The idea of the uniqueness of the URI is of key importance. Each resource should receive its own URI. Other factors, such as the "purity" of the URI can also be important, but less so than uniqueness. The second most important facet of a RESTful web service is the use of HTTP status codes. HTTP status codes (including a "description" field) define the client-side success/error reporting mechanism. Care should be given to ensure that the appropriate status code is returned from a web request.
What's New in WCF"That's all fine and good", you're thinking, "but you still haven't told me anything about implementing RESTful services with WCF." Excellent point—enough background, it's time to dig in. There are several classes and attributes that have been added which extend the existing service model allowing services to be exposed as RESTful services. System.UriTemplateAt a basic level, the UriTemplate class supports the matching or binding of a string template with name-value pairs. When defining an OperationContract, a UriTemplate is specifiedl it accomplishes two purposes. First, it provides the mapping between a request URI and an OperationContract, and second, it identifies the named values that are subsequently bound to matching OperationContract method parameters. An example of a UriTemplate instance looks like the following:
UriTemplate template =
new UriTemplate("/post/{postid}/comments?maxresults={maxresults}");
There are some important things to know about the semantics of a UriTemplate:
System.ServiceModel.Web.WebGetAttribute and System.ServiceModel.Web.WebInvokeAttributeThe WebGet and WebInvoke attributes are declared on an OperationContract. They use a UriTemplate, along with some additional information, to associate an HTTP request with an OperationContract and to optionally provide fine-grained control over the serialization/deserialization of the HTTP request/response data. WebGet allows the following Properties to be specified:
|
| Go to page: 1 2 3 Next |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers