MSDN Magazine - January 2008 - (Page 75)

protocols of the Web. In effect, WCF takes care of the plumbing in your service and lets you focus more closely on the functionality your service exposes. This article explains some of the new Web-centric features of WCF in the .NET Framework 3.5. It starts with a level-setting discussion about some of the important architectural principles in HTTP and the Web, then moves to the new HTTP programming model in WCF, and, finally, to the new syndication API. HTTP Message Basics You probably use the Web almost every day, but how often do you think about the core concepts that make the Web work? It’s not in my nature to carry on about architectural concepts, but some of the key ideas baked into the Web may not be obvious at first glance. In my view, a good understanding of these principles is a necessary first step when building services that adhere to the protocols of the Web. Keep in mind that entire books are dedicated to this topic, so I’ll only hit the high points in this article. HTTP is the transport of the Web. HTTP demands a request/ response message exchange pattern (MEP). This occurs every time you use your browser to navigate to a Web page: you make a request for a resource, and one response containing that resource is returned. The HTTP transport defines several verbs (also called methods) that add features on top of the request/response MEP, such as GET, POST, PUT, and DELETE. To illustrate some of the differences between HTTP verbs, let’s consider what an HTTP POST looks like. Here is a trimmed down version: POST /myservice/PostAlbum HTTP 1.1 HOST: www.cloudsample.net 15 At its core, an HTTP GET is a request for some resource. To illustrate, imagine you find an interesting resource on the Web (say, http://www.cloudsamples.net/pictureservices) and want to e-mail it to a friend. When your friend receives the e-mail, you expect him to be able to click on the link and view the same page you saw. You would certainly be surprised if the resource at http://www.cloudsamples.net/pictureservices suddenly became the latest news stories from MSNBC. In effect, the URI used in the HTTP GET is really a representation of a resource, and you generally don’t expect that resource to change. While there is clear You probably use the Web consensus about what an almost every day, but how HTTP GET represents, that’s not true for the other often do you think about the HTTP verbs. Consider the core concepts that make implication of sending an the Web work? HTTP DELETE message to a receiving application. Should the receiving application change its state or perform some action? Usually an HTTP DELETE is associated with a subtractive state change or action, but the specifics of that state change are not defined. The same is true for an HTTP PUT. Usually an HTTP PUT is associated with some sort of additive state change or action, but the exact shape of the change differs from application to application. Expressing Additional Information Applications that receive an HTTP GET use the information embedded in the URI to determine which resource to send as a reply. To illustrate, consider this set of URIs: contoso.com/artists/Flaming+Hammer/HitMe contoso.com/artists/Northwind/Overdone It’s really just a message that’s being sent to a listening application. In this case, the message is sent to http://www.cloudsamples.net/ myservice/PostAlbum. The message also has a payload that contains a value for the albumId field. If you boil it all down, you can think of an HTTP POST as a way to send a payload to a listening application. The payload in this example is so simple I could represent the entire payload with the number 15. For that to work, the receiving application would need to know that the number 15 maps to the value of an albumId field. Among other things, this is one of the key features offered in an HTTP GET. For example, this is what you get when transitioning from the previous HTTP POST to an HTTP GET: GET /myservice/GetAlbum/15 HTTP 1.1 HOST: www.cloudsamples.net In this case, Contoso Corporation has an application that serves resources related to music. You can probably deduce from these examples how the name of the artist and the name of the album can map into a URI: contoso.com/artists/[artist]/[album] An HTTP GET is an optimized HTTP POST, and it can eliminate the need for a payload. In effect, the URI is the payload. This results in smaller message sizes, and smaller messages result in shorter transmission times. Smaller messages and the reliance on the URI have another positive consequence: it’s easier for other applications (like proxies or browsers) to cache the results of previous HTTP GET messages for the same resource. It is important to note that HTTP GET is used far more often than any other HTTP verb. When the application receives an HTTP GET message for http:// contoso.com/artists/Northwind/Overdone, it should return a resource related to Northwind’s Overdone album. There’s clearly a pattern to the URI. It consists of some base information (contoso.com/artists) and some URI segments (or “holes”) that will contain the values of the artist and album. It is also common to embed the same sort of information in query string parameters. Though the format is different from the previous examples, the end result is the same. Here is a set of URI holes with a query string parameter: contoso.com/artists/Flaming+Hammer?album=HitMe contoso.com/artists/Northwind?album=Overdone In this case, the URI and the query string are using the following syntax: contoso.com/artists/[artist]?album=[album] The HTTP transport also uses an extensible set of headers for expressing additional information. This information can be related to caching, the type of data in the message, the name of the january2008 75 http://www.cloudsamples.net/pictureservices http://www.cloudsamples.net/pictureservices http://www.cloudsamples.net/pictureservices http://contoso.com/artists/Northwind/Overdone, http://contoso.com/artists/Northwind/Overdone, http://contoso.com/artists http://contoso.com/artists

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2008

MSDN Magazine - January 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Cutting Edge IIS 7.0 - Enhance Your Apps with the Integrated ASP.NET Pipeline World Ready - Around the World with ASP.NET AJAX Applications WCF Syndication - HTTP Programming with WCF and the .NET Framework 3.5 Wicked Code Foundations Extreme ASP.NET {End Bracket}

MSDN Magazine - January 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.