This blog has moved to http://blogs.msdn.com/b/appfabric please update your links!
ca·non·i·cal [ kə nónnik'l ] conforming to general principles: conforming to accepted principles or standard practiceIn this episode I'll tell you about my new Cannonical REST Service sample code on MSDN code gallery that demonstrates a REST Service built with WCF 4 that fully complies with HTTP specs for use of GET, PUT, POST, DELETE and includes unit tests to test compliance. Cannonical REST Entity Service (MSDN Code Gallery)Ron Jacobsblog http://blogs.msdn.com/rjacobstwitter @ronljacobs
Not not use a WCF Data Service instead and, if you need to write a custom data provider? I see the canonical REST interface as being OData and would rather implement that.
Yes - you could do a WCF Data Service instead. Doing a WebHttp service as I did provides me with more control over exactly how it behaves. I've considered trying to duplicate this with a DataService to see if I can get the same Canonical behavior - maybe someday - if someone does try this I'd love to hear the results.
I'm pretty certain you will get the same HTTP codes back as you describe, but the UriTemplate structure of OData is slightly different.
On a related subject, a while back (before OData was called OData) I wrote a blog post on data service addressing guidelines:
While this isn't about ensuring the correct use of HTTP verbs and status codes, it does raise the other subject when writing canonical REST services: addressing syntax.
I'm not so sure... You probably know more about DataServices than I do but especially when it comes to implementing a ChangeInterceptor it probably depends on the developer to correctly implement.
I also wonder about supporting eTags with DataServices - two things I have on my list to investigate but have not had time to work out yet.