This post is Step 4 in a Quick Start tutorial on how to create WCF Data Services
In Step 3 we finished exposing our WCF service. Browsing directly to the Service will display the entities that we are exposing via the service using the AtomPub format.
If we want the data returned as an alternative format e.g. JSON or XML then just modify the Request Header using the ‘Accept’ attribute, so for JSON we could ass the request header:
The best way to demonstrate this is to use a free application called Fiddler (http://www.fiddler2.com/fiddler2/)
With Fiddler loaded enter the address of the WCF service into the Composer tab but add the ‘Accept: application/json’ into the Request Headers window. Click the Execute button and you should have a JSON page returned in the Web Sessions window:
Click on the Page in the Web Sessions window to view the results.
So far we have queried the WCF service and found out how to return the data in a specific format but what about querying the actual data.
Let’s assume we want to return all records held within the Staff table. As this was one of the entities exposed by the service (see beginning of this article) then we can just append the href attribute representing this entity to the Service URL e.g.
NOTE: it is case sensitive
Again I am using Fiddler to display the results returned as JSON
Let’s call the same URL but return the results in the raw atompub format so we can analyse exactly what is being returned:
NOTE: Some browsers are automatically set up to view the raw content as an RSS feed. You may need to disable this feature in order the view the raw response from the data service.
One important point to remember is that the Data Service is purely exposing data. The whole concept is based on a RESTful architecture. This is great if we want to build a client and an alternative language or device but adds a little more complexity when it comes to modelling the relationships and navigational properties of the entities on the server-side.
WCF Data Services do however provide hints on how to navigate around the data it servers to the client. Notice the Link tags in the XML above. The first one gives us an exact pointer to the record we are viewing. You can try this yourself; simply modify the original URL to include the ID of the record you are after in brackets (this URL is also shown in the ID tag in the above XML). Now try changing the id to return different records.
Now referring back to Step 1 we created the following database structure:
There is a link between Staff and StaffTypes. This has also been exposed in the XML served up by the data service – See the second Link tag.
So by simply using the ‘href’ supplied to me in this tag I can navigate to the related StaffType record e.g.
Returns the record:
Ok now for the clever bit. WCF Data Services are based on OData (Open Data Protocol). This allows us to query the data using nothing but the URI. This is a massive subject which includes using the URI to query, filter and sort data, too much for this blog post, but I show an example just to get you started.
So let’s take the scenario that we want to return a staff record where the forename is equal to ‘Dan’ (assuming there is a person called Dan in the database!!)
We simply append a filter expression to the URI as follows:
This is great as you may have noticed we are returning, navigating and now filtering data without writing any code and so essentially giving the power to the client to request the exact data it requires.