Book Review: RESTful .NET by Jon Flanders

Title: RESTful .NET

Author: Jon Flanders

Published Year: 2009

ISBN:  978-0-596-51920-9

Publisher: O’reilly

Book Site: http://shop.oreilly.com/product/9780596519216.do

Review:

            This is a well written and very thorough book about REST, what it is, how it works and how to use it in a .Net environment. It starts at a fairly basic level on this subject and covers every aspect of this technology in detail.

            The Preface of this book indicates that the book is for .Net Developers who are familiar with REST and WCF and recommends other books as prerequisites for those not already familiar with these.  Certainly it is true that someone completely unfamiliar with these areas would find the book difficult to follow. The book does review the basics of REST pretty well, and it is clear about the purpose and use of WCF for those who, though familiar with it, might be “rusty” or not well versed.

I have been a software developer for over 30 years, and have been working in .Net since about 2004. I have written WCF services and I have been to a few lectures on REST and “played with” RESTful interfaces from time to time, but I would not consider myself an expert on either of these subjects. I did not find this book to be an “easy read” by any means; it is a highly technical book. But I did find it to be very clearly written and well organized. The author, Jon Flanders, is obviously extremely well qualified to cover the subject and does everything possible to explain each aspect of the technologies covered; including descriptions of what each feature is for, what it is not suited for, and how to use it.

After reviewing the basics and explaining the programming models, the book eases into the subject of writing RESTful services by covering Read-Only services, which may well be as much as some programmers need to know about it. But this is not a book for every programmer who wants to write a RESTful service. Instead, it is for programmers who want to know all about REST in .NET so that they can not only make informed decisions about how and where to use it (and where not to use it), but also implement it properly and securely in their projects.

Once Read-Only services have been described, the author goes into Read/Write services, Ajax Services and how to use it with Silverlight. There is also a complete chapter on programming Feeds. It then describes how to secure and consume services.

In short, I found this to be a high quality, comprehensive book and reference on the subject of writing RESTful services in .NET. It gives comprehensive, accurate coverage and is a good reference. In spite of this, it gives a competent introduction to the subject for those who don’t need or want to be pampered about it. It is practical, useful and descriptive in contrast to the standard documentation about REST that is found online, which I personally find very difficult to work with.  I found the book to be helpful and descriptive, with just the right amount of detail. It covered quite a bit more than I need for my current project, but I like this in a book. I’m sure I’ll refer back to it as needed on future projects.

BizTalk Server

A couple of years ago, I was working on a solution for a small client who wanted to set up some automated database processing with a few banks. I read up on BizTalk. It seemed to be just the thing. After woking through a very significant learning curve and getting some parts of the application working, I have concluded the following:

BizTalk was designed to fit a very real and specific need. It would probably work well for a medium or large enterprise with a significant number of Business-To-Business interactions that need automation. Even a small enterprise might successfully use it if their main business involves significant and complex electronic interaction with several other businesses. However, it is not practical for a small business that only wants to set up a few relatively simple interactions. In the latter case, it is much easier and less expensive to just code a solution directly using .Net or some other platform. This is ultimately what I ended up doing.

The main advantage of using BizTalk over direct coding is that it provides a standardized platform for setting up and managing interactions. It will keep state on complex interactions that are pending some external event for any amount of time, even if the machine goes down or is re-booted. This represents a huge amount of infrastructure which would be a very expensive and time consuming development effort to create independently. If this level of standardization and infrastructure is needed, then it's well worth it. If not needed, it is just superfluous complexity that programmers must learn about and work with, even if the application or the customer will not benefit from it.

BizTalk can be learned through courses and books. In theory, this means that one could hire programmers who already know it. In practice, BizTalk developers are a bit difficult to find, and expensive. Therefore, a company planning to implement a BizTalk application should plan on maintaining a team of BizTalk personnel to monitor and extend their application. Training a BizTalk programmer is not a matter of giving someone a quick course or having them read a book. It is a significant skill that takes some months to really attain. Even users and administrators will require training and experience with the product.

Non-trivial BizTalk applications will also require some custom code in C# or VB.Net. Therefore, using BizTalk doesn't eliminate the need for .Net programmers.

In my initial research, I found plenty of information on what BizTalk can do and how it does it. I did not find anything to give me a sense of the magnitude of the learning curve and of the effort required to create and debug "orchestrations" (interactions between computers) that work correctly. In hindsight, maybe this should have been obvious; it wasn't at the time.

Fortunately, BizTalk is available on a "try before you buy" basis, so we did not incur any licensing costs. Unfortunately, the development cost of the effort was significantly higher than the license fee would have been.

I have noticed increasingly over the past 10 years or so, that programming has become much less a matter of coding and much more a matter of finding, learning and implementing existing code and technology. BizTalk is a perfect example of this trend.

When we developers are looking for a tool that will fit a particular application, it is helpful to know what our peers have already discovered. We seldom have enough time to read the manual for a product before deciding whether to use it. Even when we do, it's difficult to get a feel for its complexity without actually working with it for a while.

When evaluating options, it always helps to hear from others who have worked with a product, successfully or not. I hope that this entry will not only be of help to someone evaluating BizTalk, but that it will also encourage other developers to blog their experiences, good or bad, with the tools they use.