While there are many different ways to implement web services the two predominate architectural styles are REST (REpresentational State Transfer) and SOAP (Simple Object Access Protocol). Each style has is own pro's and con's and it is necessary to objectively balance the appropriateness of each when selecting the implementation of your next service. So what's the difference at a high level between the two?

SOAP (WS-*) services are geared toward the enterprise and are inheritently more complex. For each SOAP service you define a contract using the Web Service Definition Language (WSDL). This contract specifies precisely the XML request and response messages needed to interact with the service. The SOAP (WS-*) standards address things like reliability, transactions and message-based security which are important when dealing with any value added transactions. Obviously there is a cost for this functionality in terms of overhead and complexity.

If a SOAP service is consider the 'yin', then the REST service would definitely be the 'yang'. Simple to implement with no contract to define a REST service can be broken down to four actions:

- GET - Gets the Resource
- POST - creates the Resource
- PUT - Updates the Resource
- DELETE - Deletes the Resource

This simplicity means quicker development time, lower overhead although you sacrifice features. For services that are dealing with non-critical data REST services are definitely the way to go.

So which will you choose? We say let the REST versus SOAP debate rage on.Luckily for you, you don't have to be caught in the middle. The Microsoft Windows Communications Foundation (WCF) framework provides you with the flexibility to easily change the method your service uses to communicate and even allows you to service both REST and SOAP requests with the same service.