Tell Your Services to Take a REST Sorry, that's the best pun I could come up with today. I think all the Guiness and buffet is slowing down my brain. But what better time then now to write a tech post! REST - REpresentational State Transfer - is a new style of web service that is gaining in popularity, especially with recent support from .NET. The general pricinples of RESTful services include: Application state and functionality is abstracted into resources Every resource has a unique address All resources share a uniform interface for data transfer, including a constrained set of operations and content types Uses a client-server, stateless, cacheable and layered protocol Although you could technically make a RESTful service using any sort of data definition and protocol, the more common ones use HTTP and either XML or JSON to transfer data. The basic idea behind RESTful services are to present your CRUD operations in the context of resources and make it as available as possible. You, as a consumer of my service, shouldn't care how I implemented my service or have to code around some sort of messed up data type that might be proprietary to my development platform, and have to worry about what I called my methods. Instead, I tell you what resources I have, what language I use to define them, and how to get to them. For example, getting a list of customers from my service might look like this: Also in comparison to the