REST in WCF – Part I (REST Overview)
I will be doing an interactive theatre session at TechEd in a few days (if you are going to be there, stop by – info below). The topic of the session is REST in WCF. I thought it might be nice to blog about the topic, as I review my demos, so here goes:
I have given this talk a number of times in the past and usually start with a brief overview of REST. I’ll do the same here, but before I begin (and you start drafting your response), I want to bring up the fact that EVERYONE seems to have a different definition of REST. Some of these definitions are more stringent, while others are more liberal. I tend to envision a continuum of RESTiness (as GW would put it). See below…
Some basic thoughts behind REST are as follows:
- Simpler is better
- The web has been highly successful
- The web is quite simple
- The web follows a few guiding principles, and those principles have remained stable over time
- Web Services should follow "the way of the web"
In keeping with the idea that differing people have differing definitions of REST, there are certainly some characteristics that influence whether a service is RESTful at all, and if it cound be considered RESTful, where it may fall on this continuum. Here are some (not all) of those characteristics:
- The use of appropriate HTTP verbs (GET, PUT, POST, DELETE being the major verbs) - Definitions falling on the HI-REST side tend to be more stringent about which verb is used for particular scenarios. For example a HI-REST implementation may use GET for fetches, DELETE for deletes, PUT for inserts and updates and POST for appends, while a LO-REST solution may use an overloaded POST for inserts, updates, deletes and appends.
- The choice of a viable Representation Format – HI-REST solutions tend to lean toward standard representation formats, whereas some LO-REST solutions may see POX as ok.
- The use of well constructed URIs – HI REST solutions tend toward very descriptive URIs and generally dissuade the use of query strings, whereas some LO REST solutions see the use of QueryStrings as ok.
- (There are others: the inclusion of links to related info in the payload, the use of appropriate http response codes to name two)
The reason I don’t take a definitive stand on what the "Definition of REST" should be is not that I don’t care. The reason is that, from the perspective of WCF, the specific definition does not matter. WCF supports REST on both ends of the continuum. In fact, in tomorrows post, I’ll build a LO-REST implementation, while in subsequent posts, I will illustrate solutions further toward the HI REST side of the continuum.
If none of this is making much sense yet, that is ok. The subsequent posts will provide concrete examples (including code).