So if REST is so great should I always build my systems as REST based ones? Well some people would argue that but there are issues in REST.

No metadata

As may be apparent from the REST benefits above, REST is a pragmatic way of building services and this pragmatism currently means there is no metadata. In other words the consumer has to implicitly know what a service requires and what it may return. Hopefully testing the application should drive out whether assumptions about message formats are correct and the pragmatism does not absolve the service provider from taking a responsible attitude to service evolution.

No standard for actions

The next valid actions are a crucial concept in REST and yet there is no standard way of encoding this information and no agreed place of putting this information. There has been some discussion about using ATOMPub as a mechanism but this is far from an agreed standard.

Tooling is rudimentary

On the .NET platform there is little tool support for consuming REST services. With the lack of metadata you are left with having to consume the saw format of the message whether this XML, JSON, an image or something else. There is growing support on the service side with .NET 3.5 WCF extensions and the upcoming ASP.NET routing infrastructure shipping in .NET 3.5 SP1.

Conclusion

REST is a very powerful way to build services. The model lends itself to high scalability as it uses the same model as the web. It is particularly applicable to services that are exposed on to the public internet as generally all a consumer needs to be able to do is manipulate XML and talk HTTP - which every platform supports.

In the first part of this article I have introduced REST and outlined its benefits and issues. In part two I will show you how to build and consume REST based services using WCF, ASP.NET and LINQ to XML.