CheckConditionalRetrieve doesn't feel quite right

Topics: Web Api
Mar 23, 2011 at 5:34 AM

To the WCF HTTP team:

For what it is worth I'll share my experience to date with the construct in hope that you'll see an oppertunity to clean up an interaction:

  • I hate that CheckConditionalRetrieve breaks in to the debugger because it is throwing an exception when nothing is wrong.
  • Why throw an exception? Nothing went wrong.  I understand it is trying to end the flow, but it seems the calling method should be responsible for that.  The method is called CheckConditionalRetrieve, which implies is should return a boolean or other result of some type.
  • This is top of mind because I see that pattern for using the check all over the Conical Rest examples, eventually it will become too baked in to change...

Thanks!

-Brian

Coordinator
Mar 23, 2011 at 5:47 AM

Brian, are you trying to use WebOperationContext with our new web api bits, or with .NET 4.0? It doesn't work with our new web api as you use HttpRequetMessage / HttpResponseMessage params on the method signature in order to access headers/etags, etc.

Mar 23, 2011 at 7:11 AM

Thanks for the quick reply Glenn!  Let's see if I get this right:

I'd like to answer "both". I am using your new bits in a .NET 4.0 project.  I was pulling the patterns from the CannonicalRESTService examples that Ron Jacobs put together. I'll assume by your response that "WCF 4.0 WebHTTP" that Jacobs was showing off are the bits that shipped with .NET 4 where as this project "WCF HTTP" is the next evolution? And if I am way off I'd love a pointer to an article that clears that up.

Adding to my confusion are the online templates for "WCF REST Service Templates".  That is where I started. Based on your reply I am now guessing those templates are not maintained by this project.

Back to square 1.

Thanks!

Coordinator
Mar 23, 2011 at 7:22 AM

WebOperationContext no longer works with our new web api as we have introduced a new way to access HTTP in a much cleaner and testable fashion. You basically just add HttpRequestMessage and HttpResponseMessage parameters to the signature of your methods and you can directly work with it. You don't need static apis. For example see this walkthrough which illustrates acessing the raw messages. http://wcf.codeplex.com/wikipage?title=Exposing%20a%20service%20over%20HTTP%20using%20HTTP%20Messages

We don't have CheckConditionalRetrieve (which has a ton of issues, but you can easily access the IfMatch, IfNoneMatch headers to do whatever logic you like. We also offer the new processor model for addressing such concerns outside the operation as a cross-cutting concern.

This project is the next stage of evolution for WCF HTTP in .NET 4.0.

The online templates are for WCF 4.0, they are not for our new web api. We will have new templates in the future, we just aren't there yet.

Thanks

Glenn

Feb 12, 2013 at 7:09 PM
Edited Feb 12, 2013 at 7:16 PM
We don't have CheckConditionalRetrieve (which has a ton of issues, but you can easily access the IfMatch, IfNoneMatch headers to do whatever logic you like. We also offer the new processor model for addressing such concerns outside the operation as a cross-cutting concern.
So I guess let me ask this: if I were to run an operation inside of my service and generate an eTag string, what is the equivalent (using HttpRequestMessage) to saying:
_webOperationContext.IncomingRequest.CheckConditionalRetrieve(etag);
(where etag is a string)

Our previous code would run CheckConditionalRetrieve and catch the exception (if matched) by setting the OutgoingResponse code to 304 and supressing the body.