REST, WCF 4, Forms Authentication, and Custom Clients (Part 1 of 3)
SOAP and REST Compared
REST services are the new “hotness.” All of the cool kids are doing them. I (not that cool of a kid) feel as though I’ve been left behind -- holding onto my SOAP messages like an old curmudgeon holding on to his last dollar. After all, SOAP-based services have served me well; all the way back to the .ASMX days. So, I’m the first to admit that traditional (SOAP-based) web services still have a place. They are extraordinarily easy to use, nowadays, because the tooling around them is so polished. On top of that, I can’t think of a platform that doesn’t support them, today.
[more]
The argument against these traditional services is that they are “heavy.” The SOAP envelope that your actual message gets wrapped in, adds weight and uses extra bandwidth. It also means that both the consumer and service need to have logic to “open the envelope” and understand it. Granted, this is hidden in most implementations, nowadays, but it still has to exist at some level. In the example above, you can see how verbose the request to a parameter-less method and it’s Boolean result can be.
Another argument against SOAP is that it is redundant. If you look at the HTTP protocol, it already has its own set of operations in the form of “Verbs” (POST, GET, PUT, DELETE, etc.). SOAP uses a header in the HTTP message (SOAPAction to be exact), to declare the operation you want the service to perform. REST simply uses a URL and an HTTP verb -- both of which would already be there for a normal HTTP request. Below, you can see a typical REST request and response. In many ways, it looks very much the same as a SOAP request/response, but as you can see, the request is much small and simpler; as is the response.
Message format is a given in the SOAP-based service world. Almost all SOAP services you will encounter “in the wild” use XML for their message format. Not every SOAP implementation has to use XML; SOAP can use other formats, but most choose XML because they have to deal with the SOAP envelope (which is XML), anyway. So, because of that, it’s almost a no-brainer to use XML since you’re in that space, already.
REST services, on the other hand, can easily switch between message formats. So, if you need XML for your .NET deserialization code, but require JSON for your JavaScript snippets, REST can easily accommodate your needs. The good services do this automatically by looking at the “Content-Type” header in the HTTP message. The not-so-well-thought-out services can still do this, but may require you pass an argument in the URL to choose your format. And, because you don’t have any message envelopes to get through before you see your data, parsing the returned data is trivial.
Below, you can see an example of a REST service method (the same one as the example above), but the request’s “Content-Type” header is set to “application/json” instead of “text/xml.” You’ll notice the response now includes a valid JSON-formatted date string instead of XML.
What is Missing from REST
Like I said before, I have used SOAP for almost all of the service work I’ve done, in the past. I like how Visual Studio and WCF creates nice, easy to understand objects for me. I like being able to point at a WSDL and have my service client generated for me. I like having the abstraction layer / SOAP implementation handle context for me. I like not having to think about the underlying HTTP protocol.
On top of all of that, my brain works in the RPC-like service domain, very well. I name my methods after the action they perform. With REST, you concentrate more on your entities and utilize the existing verbiage to perform the actions you want.
If you use WS-* with your SOAP services, there is a chance you’ll run into some roadblocks. For federated security or reliable messaging, you’re probably going to want to stick with SOAP and WS-*. Transactions are another piece of the puzzle I don’t quite have a solution for yet, but I’ve seen examples of possible solutions, so there’s hope there.
Other than those things mentioned above, you can do most anything with a REST service that you could with a SOAP service. Some might even argue that you can do it more elegantly – though beauty is in the eye of the beholder.
What’s Next
In the next part of this post, I’ll detail how you might create a REST service (with pretty URLs, no less!) using WCF 4. In the part following that, we’ll take a look at securing the service with ASP.NET’s MembershipProvider (also known as Forms Authentication) and how we can write a simple console application that consumes the service.