June 2011 - Posts
The term REST originated with Roy Thomas Fielding in his paper on Architectural Styles and the Design of Network-based Software Architectures. In this paper he described a way to leverage the basic principles behind the web and apply those to business applications. He argues that the World Wide Web is in fact one of the largest applications used by millions of people every day and one that, despite frequent predictions to the opposite, has managed to scale very well.
If the web as we know it is such an immensely scalable and quite reliable application when why don’t we build our own distributed systems with the same architecture?
Where are a couple of reasons here as I see it:
- The standardized SOAP protocol has become quite popular over the last few years. The promise of a standard based messaging approach is very appealing because it promises a lot if interoperability. And the fact it’s standards based made it easy for vendors, like Microsoft, IBM or Oracle to name a few, to implement API’s around it. And with them having put a lot of work in it they tend to push people to using their products.
- The architecture of the web is actually quite poorly understood by a lot of people. Sure they use their browsers and read websites. And most likely they use even more of the web without realizing it. But they don’t know how it really works, just sort of.
- The people who do know how the web works usually didn’t think of it as appropriate for their applications. After all the web is such a massively big thing. As a result it’s architecture can’t possibly be useful for a much smaller business application.
Well it turns out the last group was wrong 
As Roy describes in his paper the web is actually build around a very limited set of relatively simple technologies that have proven themselves over the years. And with an understanding of these basic technologies it isn’t hard to incorporate the same basic architecture into our own applications 
Of course that doesn’t mean that SOAP is wrong and REST is right.
Like all architectures REST has it strengths and weaknesses. Using an architecture like REST blindly will lead to problems as there are numerous cases when SOAP will be more appropriate.
Some of the differences between SOAP and REST are:
| | SOAP | REST |
| Style | Operation centric | Resource centric |
| Addressing | Single URL for each service, no matter how many operations | A URL points to a resource. Different resources have different URI’s. |
| Transport | Doesn’t care, it’s just a means of getting bits from A to B. No real use of transport features. | HTTP only. Uses as many of the HTTP standard features as possible. |
| Request meta information | Passed in the SOAP header as part of the request body. | Passed as HTTP Message Headers. |
| Action to perform | Passed as part of the SOAP header in the message. | Uses the HTTP Method to determine what action to perform. |
| Message formats | Always XML using a well defined envelope containing a header and the body. | Often XML of JSON but the developer is free to choose whatever format is most appropriate at the time. The same resource(=UR) can be represented with different formats depending on the clients needs. The client can use the standard HTTP Accept header to specify the format required using MIME Media Types. |
| Result status | Using faults as part of the message body. | Uses HTTP Status Codes to indicate the result status of a request. |
| Caching | Only with custom code. | Responses can be cached using standard web infrastructure. |
| Standards | Lots of standards around different action. Commonly grouped together as the WS-* specification. | Besides HTTP there are a few standard like AtomPub that are commonly used. However these are not a requirement for building Restful services. |
| Tooling | Lots of tooling support like Add Service Reference in Visual Studio | Due to the lack of standards there is very little specific tooling support. |
So I guess it boils down to that SOAP want to do everything over any transport with lots of, sometimes complex, standards while REST is much less formal and uses as much as possible from the HTTP standard but leaves the developer much more flexibility.
Both approaches have their strong and weak places so you should take a good look at what is best suited in your situation.
Enjoy!
www.TheProblemSolver.nl
www.dotnetevents.nl
I recently did a few blog posts showing the basics of how to get started with the WCF Web API but before I continue I think it is best to start with the why instead of how. A lot of people will be familiar with writing SOAP style services but not everyone is quite as familiar with the REST approach so I guess that takes a bit of explanation.
This subject is a bit long 
for a single blog post so I am going to do a number explaining what REST is, the difference with SOAP and how to build these Restful services using the WCF Web API. Of course the WCF Web API is still in a preview state so some of the technical things are subject to change over time but the general principal of building Restful services isn’t going to change a lot.
Some of the topics I am expecting to cover:
- Basic principals of a REST service including (here):
- Different message formats
- Using hypermedia
- Scalability
- Security
- Software engineering principals:
- IOC and Dependency Injection
- Testing with InMemoryRepository
If you think I am forgetting an important part here let me know and I will add it to the list of things to write about.
Enjoy!
www.TheProblemSolver.nl
www.dotnetevents.nl
WCF might use the WS-* SOAP standard for communications but the WS-* specs leave vendors with a lot op maneuvering room when it comes to how to exactly implement things. As a result doing interoperable work between WCF and, for example, an IBM WebSphere server can be quite tricky to setup. Something I have experienced all to often 
Fortunately Microsoft has now released the WCF Express Interop Bindings that should make live quite a bit easier. These binding are preconfigured for a number of common platforms like Apache, IBM WebSphere or Oracle WebLogic and should make things quite a bit easier. If only I could have used these several years ago, but you can now 
Read more about the WCF Express Interop Bindings in the announcement here or here.
You can download them from CodePlex here.
Enjoy!
www.TheProblemSolver.nl
www.dotnetevents.nl
In deze podcast spreek ik met Alex Thissen over het beveiligen van applicaties. Ze bespreken veel voorkomende kwetsbaarheden en wat je kan doen om je hier tegen te verdedigen. Ook hebben ze het over federated security en Windows Identity Foundation en wat dit voor de toekomst gaat betekenen.
http://www.dotned.nl/PodCasts.aspx?id=10
PS: Dutch language only 
www.TheProblemSolver.nl
www.dotnetevents.nl
Warning: This post is based on a prerelease version of the WCF Web API
In my previous blog post I showed how to add to and use the new WCF Web API a console application using NuGet. Now that works but it is far more likely that you will want to be using IIS and host the REST service as part of a web application. So in this blog post I am going to show how to do the normal thing 
I Created an ASP.NET MVC 3 app to host the REST service. Not that there is anything specific to MVC I need here, all I need is a web site and I could have started with a WebForms application just the same. I just prefer the MVC approach, you might not.
Just like in this post we can add a reference to the WCF Web API to our project. Just like in the post the best package to start with is the WebApi.All.
The service we are going to host is pretty simple for now. All we can do is retrieve a list of books or get an individual one. In future blog posts we are going to expand on that and make our service more interesting. For now the service looks like this:
[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class BooksService: IDisposable
{
private readonly IBooksRepository _repo;
public BooksService(IBooksRepository repo)
{
_repo = repo;
}
public BooksService()
: this(new BooksRepository())
{
}
[WebGet(UriTemplate = "")]
List<Book> GetBooks()
{
var result = _repo.GetBooks();
return result;
}
[WebGet(UriTemplate = "/{id}")]
Book GetBook(int id)
{
var result = _repo.GetBook(id);
return result;
}
public void Dispose()
{
if (_repo != null)
{
_repo.Dispose();
}
}
A few interesting things to note here:
- We are using the standard WCF ServiceContract attribute to indicate this is a service.
- We are using the AspNetCompatibilityRequirements to make sure the service runs as part or the ASP.NET pipeline. This means we can use the ASP.NET routing engine.
- The individual service operations are decorated with the WebGet attribute specifying the UriTemplate. Note that you can set the RequestFormat and ResponseFormat on the WebGet attribute but this is completely ignored. Request and Response formats are done a different way, more about that in a future blog post.
- The OperationContract attribute is not used as we are not going to expose these operations using SOAP.
Next we need to make sure we actually host the service so clients can call into it. There are several ways we can do this. For example we can create a ServiceRoute() and add it to the routes collection like so:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.Add(new ServiceRoute("books", new HttpServiceHostFactory(), typeof(BooksService)));
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
);
}
This works fine for our simple service but a far better approach is to use an IHttpHostConfigurationBuilder create our service host for us. Right now that doesn’t buy is much but it will allow us to easily add functionality to the HttpServiceHost in future blog posts. So instead of the code above I am going to use the code below to do the same:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
var builder = HttpHostConfiguration.Create();
routes.MapServiceRoute<BooksService>("books", builder);
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
);
}
These steps, and adding the required IBooksRepository and its implementation, result in a working service the URL “books” maps to the collection of all books and the URL “books/3” maps to the book with id 3 using the template. Navigating to the URL in browser results in the following:
Pretty nice
A non browser client application can consume this REST service quite easily using a standard HTTP API available. For example using a HttpWebRequest like this:
var request = HttpWebRequest.Create("http://localhost:28330/books");
var response = request.GetResponse();
var reader = new StreamReader(response.GetResponseStream());
Console.WriteLine(reader.ReadToEnd());
or even simpler using a WebClient like this:
var client = new WebClient();
Console.WriteLine(client.DownloadString("http://localhost:28330/books"));
Both will produce exactly the same XML being printed.
Download the source code.
Enjoy!
www.TheProblemSolver.nl
www.dotnetevents.nl
Warning: This post is based on a prerelease version of the WCF Web API
In my previous blog post I showed how to get started with the new WCF Web API but one thing I skipped is how to install and add it to your project first. So in post I am going to add that information.
The easiest way to get started is to use NuGet and add the WCF Web API package to your project. There are several different packages for the WCF Web API but the one named WebApi.All is the easiest to get started with as it contains all relevant assemblies.
However when I try to add the package to a simple console application I get the following less than useful error message when the installation fails.
Install failed. Rolling back...
Error HRESULT E_FAIL has been returned from a call to a COM component.
The reason is that the WCF Web API tries to add a reference to some assemblies that are not available in the .NET 4 Client Profile so make sure to switch this to the full .NET 4 Framework and adding the package will work.
Fortunately this problem won’t occur when you use an ASP.NET project to add the package reference as they default to the full .NET Framework in the first place.
Enjoy!
www.TheProblemSolver.nl
www.dotnetevents.nl