This is part 3 in this series where I am building an Azure shopping cart application from the ground up. In this post, I will create a RESTful service using WCF and host it in Windows Azure. This service will source it’s data from Azure Table Storage. I will then illustrate how to consume this service from a Silverlight component hosted in Windows Azure. Giddyup.
(In part 2 I illustrated how to set up and access Azure Table Storage in both the development environment, as well as in the cloud. I created a Wine table, added a few entities and retrieved them both locally and from the cloud. I did all this taking advantage of the ADO.NET Data Services .NET Client Library and the StorageClient sample application.)[ Read More → ]
I recently received a question regarding effective error handling when working with RESTful web services. In this post, I will illustrate how to expose, as well as handle errors effectively when working with RESTful WFC services.
[ Read More → ]
In yesterday’s post, I illustrated using the WCF REST Starter kit to create a RESTful service that exposes a sample ATOM feed. We accomplished this by simply creating a new service using the ‘WCF ATOM Feed Service’ item template. This template created an svc file with a REST-friendly factory. It also created a cs file with one operation that returned an Atom10FeedFormatter. The feed contained dummy syndication items. In this post, I will show you how to update this code to expose custom data. In this case, we will expose a feed of wines from a wine catalog.[ Read More → ]
One of the key enabling factors of the browsable web was the use of a standard representation format: HTML. Web page authors need only understand one format and browsers need only understand how to render one format. In other words, if I authored a web page in HTML, it was easily consumable because every browser understood our standard representation format. This same concept can and does hold true for our RESTful services. If my service returns a standard representation format like ATOM, there are already a host of clients that can consume the response. Conversely, if my service returns POX (plain old XML), we are starting at ground zero.
The key to choosing a representation format is to choose one that is standardized, fits your problem domain and is widely understood in that domain. The ATOM Syndication Format is a standardized XML-Based format for web feeds.[ Read More → ]
A common scenario you may encounter when designing your RESTful services is supporting clients that only work with GET and POST. Two such clients on our stack are Silverlight 2 and our ASP.NET AJAX Client Libraries (out of the box). This brings about a quandary: should I design a HI-REST service interface (support GET, PUT, POST, DELETE) and not support these clients or should I design a LO-REST service interface (only support GET and POST) and support clients such as these. Fortunately, for you, these are not the only answers to this problem.
In this post, I will illustrate how to "tunnel" PUT, DELETE or any other HTTP Method over POST. What I mean by tunneling over POST is that you actually use an HTTP POST, but you pass additional information that allows your call to be routed to the appropriate service operation that supports other Methods. In this case, we will support passing the "real" method we want to call in an X-HTTP-Method-Override HTTP Header. This would have been a chore prior to the release of the WCF REST Starter Kit. Now, however, it is quite simple. Let’s take a look…[ Read More → ]
So far in this series (click here for an index of the complete series, as well as supporting screencasts), I have illustrated how to develop both a LO-REST, AJAX-Friendly service, as well as HI-REST services adhering to the unified API of HTTP. In the very first post, I touched on some aspects of REST, but I haven’t spent much time on the benefits of following a RESTful architectural style. I made mention of the fact that RESTful services follow the "way of the web". As it turns out, this proves to be quite powerful.
The first 2 sentences of Section 13 of the HTTP 1.1 Specification highlight this point quite well: "HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible." What can be gleaned from this is that HTTP, the underlying protocol used by the web, is explicit about how to support caching responses. Clients (such as browsers), proxies and web servers all participate in caching responses, providing the scalability required by applications running on the web. RESTful service architectures seek to take advantage this infrastructure for their services.[ Read More → ]
Resources in REST
Arguably, the most fundamental concept in REST is that of a resource. It is best to think of it as a conceptual representation of an entity or entities. Blah, blah, blah, conceptual, blah blah blah, representation, blah, blah, blah entity. What does all of that mean anyway? Think of it this way, if you can create a link to it, it is a resource. Now what does conceptual representation mean? Essentially, it means that the resource is an abstraction. It is not the underlying entity itself, rather a mapping to that entity… and that mapping may change. Whoa, the mapping may change? How is that? Consider the example that you wanted to expose the top 10 best selling books at your online store. The resource would be those top 10 best selling books. It is clear that those would change over time.[ Read More → ]
As some of you know, I am in the midst of a blog series on REST in WCF. Further, I have been hard at work on a series of screencasts on the same subject (in conjunction with Ron Jacobs). My colleague Tim Heuer relayed to me that I didn’t have a single post that we can point a person to that provides links to all of the posts and screencasts. I will keep this post updated with all of the info:
Blog Series:[ Read More → ]
In Thursday’s post (Part VII), I illustrated how to implement insert/update functionality in a HI-REST service operation. In this post, I will illustrate implementing a delete. Unlike the previous post, there is little debate how to implement a RESTful delete. Further, the lessons we learned in the previous few posts will make implementing the delete trivial. I’m going to start motoring through…[ Read More → ]
In parts I – VI, I illustrated exposing fetch functionality in a LO-REST, AJAX-Friendly manner, as well as in a HI-REST manner. I further illustrated how to consume both via an AJAX client. In this post I am going to discuss and illustrate how to implement insert and update functionality in a HI-REST manner. If you remember back to the point I made in Part I of this series, I suggested that there are many definitions of REST and put forth the idea of a REST continuum. This is a healthy manner to discuss REST, in that it allows for many interpretations. If I have learned anything over my years of coding is that there are always many ways to solve a business problem with code. Not only are there many ways, but there are many correct ways.[ Read More → ]